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