2 Replies Latest reply on Nov 4, 2013 2:15 PM by bleathem

    Change in resource packaging

    michpetrov

      Hi all,

       

      we needed to split Core and UI packed resources for RF 5 to work with RF 4.5 (RF-13280). To achieve this I have changed the pack parameter of the resource plugin to accept a string (filename) instead of a boolean.

       

      This should not cause any issues with current configurations since users should not be referencing the packed files directly (they will only end up being named true.js/true.css instead of packed.js/…). It will however cause an issue where packing is explicitly disabled (i.e. <pack>false</pack>). The old parameter defaulted to false so there was no reason for doing this but I noticed we were doing in RF 4 anyway. Are we expecting this to be a significant case?

       

      Michal

        • 1. Re: Change in resource packaging

          For backward compatibility I would say we should sanitize "false" and treat

          it as special case null.

          The same could apply to "true", where we can treat it as "packed".

           

          Also, we could print warning for both, "true" and "false" options.

           

          Wdyt?

           

           

          On Mon, Nov 4, 2013 at 11:58 AM, Michal Petrov <

          richfaces-dev@lists.jboss.org> wrote:

           

          Hi all,

           

          we needed to split Core and UI packed resources for RF 5 to work with RF

          4.5 (RF-13280 (https://issues.jboss.org/browse/RF-13280)). To achieve

          this I have changed the pack parameter of the resource plugin to accept a

          string (filename) instead of a boolean.

           

          This should not cause any issues with current configurations since users

          should not be referencing the packed files directly (they will only end up

          being named true.js/true.css instead of packed.js/…). It will however cause

          an issue where packing is explicitly disabled (i.e. <pack>false</pack>).

          The old parameter defaulted to false so there was no reason for doing this

          but I noticed we were doing in RF 4 anyway. Are we expecting this to be a

          significant case?

           

          Michal

           

          Posted by forums

          Original post: https://community.jboss.org/message/844299#844299

           

          _______________________________________________

          richfaces-dev mailing list

          richfaces-dev@lists.jboss.org

          https://lists.jboss.org/mailman/listinfo/richfaces-dev

           

          • 2. Re: Change in resource packaging
            bleathem

            On Mon 04 Nov 2013 08:50:53 AM PST, Lukáš Fryč wrote:

            For backward compatibility I would say we should sanitize "false" and

            treat it as special case null.

            The same could apply to "true", where we can treat it as "packed".

             

            Also, we could print warning for both, "true" and "false" options.

             

            Wdyt?

             

            +1

             

            The only other alternative is to introduce a new parameter, but I think

            that would unnecessarily muddy up the API.

             

            Brian

            _______________________________________________

            richfaces-dev mailing list

            richfaces-dev@lists.jboss.org

            https://lists.jboss.org/mailman/listinfo/richfaces-dev