-
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
-
2. Re: Change in resource packaging
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
https://lists.jboss.org/mailman/listinfo/richfaces-dev