Paul, Not sure I agree that the approach violates the spec, given it would be 'off' by default (it seems similar to Trinidad's existing customization of the 'client' state saving setting), but I do see your point on documentation. For sure your approach could also work. I'll take a look at this when I get some time and see what works best, as no doubt the current implementation will likely make one of these approaches easier than the other.
Thanks, Danny On Mon, Feb 25, 2008 at 5:01 PM, Paul Spencer <[EMAIL PROTECTED]> wrote: > Danny, > Sounds like a good idea. I am not sure if the non-spec compliant use of > the parameter javax.faces.CONFIG_FILES in conjunction with a parameter > not defined by the spec, like > org.apache.myfaces.ENABLE_WILD_CARD_IN_CONFIG_FILES, > would violate the spec. At the very least it would complicate the > documentation of javax.faces.CONFIG_FILES. > > Would a better solution be to create a parameter, like > org.apache.myfaces.ADDITIONAL_CONFIG_FILES, which supports wildcards and > pattern matching? The resulting set of configuration files would be the > config files identified by BOTH parameters. > > Paul Spencer > > > > Danny Robinson wrote: > > Guys, > > > > I don't think it's possible to dynamically specify wildcard config > loading > > patterns for JSF currently. However, most all other frameworks today > seem > > to be able to handle something similar for loading files by > naming/location > > conventions. I know JSF will pick-up META-INF/faces-confg.xml inside > the > > jars, but my concern is mainly with navigation rules and creating > modular UI > > bundles. > > > > Would there be appetite to have this as feature in the MyFaces > > implementation, disabled by default (for compliant with spec.), but > enabled > > via a config setting? > > > > Thanks, > > > > Danny > > > > -- Chordiant Software Inc. www.chordiant.com
