<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Users will be editing and playing with our existing themes to figure
    how to extend things.  I'll go as far to say that *EVERY* user will
    do this.  It needs to be really easy to do and is just as important
    as playing nicely with the patch mechanism.  <br>
    <br>
    <br>
    <div class="moz-cite-prefix">On 2/15/2016 4:08 AM, Stian Thorgersen
      wrote:<br>
    </div>
    <blockquote
cite="mid:CAJgngAcOj-fX-WShy+mRi=Z-03Qidzpa6+SnrgG3ZuoRB73kBA@mail.gmail.com"
      type="cite">
      <p dir="ltr">Keeping it as is isn't an option IMO. There's a
        pretty big chance that we will need to patch themes. There's
        several issues with that as it stands:</p>
      <p dir="ltr">* Users need to deal with two separate patching
        mechanisms and we also need to create tools, patches,
        documentation separately<br>
        * What if users change the built-in themes, rather than
        extending. We tell users not to, but if they can they will. If a
        built-in theme has been changed patches probably won't work<br>
        * EAP supports roll-back of patches, applies patches atomically.
        It's a proper tool that helps users to do it right<br>
        * EAP supports domain mode</p>
      <p dir="ltr">What Stan is proposing might be worth considering. It
        doesn't solve the case that users can modify the files though.</p>
      <p dir="ltr">I would actual prefer that built-in themes are always
        loaded from the module, but we have the templates available in
        exames/themes/templates.</p>
      <p dir="ltr">Another relevant thing is what do we do when users
        have modified templates. How can we help them apply the required
        changes to the custom template?</p>
      <div class="gmail_quote">On 12 Feb 2016 19:32, "Stan Silvert" &lt;<a
          moz-do-not-send="true" href="mailto:ssilvert@redhat.com"><a class="moz-txt-link-abbreviated" href="mailto:ssilvert@redhat.com">ssilvert@redhat.com</a></a>&gt;
        wrote:<br type="attribution">
        <blockquote class="gmail_quote" style="margin:0 0 0
          .8ex;border-left:1px #ccc solid;padding-left:1ex">
          <div text="#000000" bgcolor="#FFFFFF">
            <div>BTW, how do you deal with theme changes on OpenShift? 
              Looks like a year ago the answer was, "fork the
              cartridge".  Is that still the only solution?<br>
              <br>
              <a moz-do-not-send="true"
href="http://lists.jboss.org/pipermail/keycloak-user/2015-February/001675.html"
                target="_blank">http://lists.jboss.org/pipermail/keycloak-user/2015-February/001675.html</a><br>
              <br>
              On 2/12/2016 12:46 PM, Bill Burke wrote:<br>
            </div>
            <blockquote type="cite"> Keep it the way it is, IMO.  Write
              directions on how to handle a theme patch.<br>
              <br>
              <div>On 2/12/2016 11:01 AM, Stan Silvert wrote:<br>
              </div>
              <blockquote type="cite">
                <div>Another way to deal with this might be to unjar the
                  files ourselves at startup.  The files could live in
                  the same place they live today.  <br>
                  <br>
                  We would just have keep track of versioning.  If a
                  newer version of the theme is installed we overwrite
                  the old version in standlone/configuration/themes.  Of
                  course, if the theme has been modified by the user we
                  wouldn't overwrite, but instead just unjar to another
                  location.<br>
                  <br>
                  On 2/12/2016 9:44 AM, Stian Thorgersen wrote:<br>
                </div>
                <blockquote type="cite">
                  <p dir="ltr">Currently we include built-in themes in
                    the themes jar as well as extracted to
                    standalone/configuration/themes. We have to remove
                    the extracted files.</p>
                  <p dir="ltr">This is due to patching. The patching
                    tools only supports patching modules, not files. If
                    we need to patch the theme templates (quite likely
                    we will) we can then only patch the jar. As the
                    extracted themes override the jar it won't work
                    unless we remove them.</p>
                  <p dir="ltr">The main problem with removing the
                    extracted files is that they are useful for someone
                    that needs to modify the templates. I think the best
                    would just be to give people instructions on how to
                    extract these from the jar. It's just a zip after
                    all.</p>
                  <p dir="ltr">Thoughts??</p>
                  <br>
                  <fieldset></fieldset>
                  <br>
                  <pre>_______________________________________________
keycloak-dev mailing list
<a moz-do-not-send="true" href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a>
<a moz-do-not-send="true" href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a></pre>
                </blockquote>
                <br>
                <br>
                <fieldset></fieldset>
                <br>
                <pre>_______________________________________________
keycloak-dev mailing list
<a moz-do-not-send="true" href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a>
<a moz-do-not-send="true" href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a></pre>
              </blockquote>
              <br>
              <pre cols="72">-- 
Bill Burke
JBoss, a division of Red Hat
<a moz-do-not-send="true" href="http://bill.burkecentral.com" target="_blank">http://bill.burkecentral.com</a></pre>
              <br>
              <fieldset></fieldset>
              <br>
              <pre>_______________________________________________
keycloak-dev mailing list
<a moz-do-not-send="true" href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a>
<a moz-do-not-send="true" href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a></pre>
            </blockquote>
            <br>
          </div>
          <br>
          _______________________________________________<br>
          keycloak-dev mailing list<br>
          <a moz-do-not-send="true"
            href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a><br>
          <a moz-do-not-send="true"
            href="https://lists.jboss.org/mailman/listinfo/keycloak-dev"
            rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a><br>
        </blockquote>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
keycloak-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/keycloak-dev">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a></pre>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
Bill Burke
JBoss, a division of Red Hat
<a class="moz-txt-link-freetext" href="http://bill.burkecentral.com">http://bill.burkecentral.com</a></pre>
  </body>
</html>