For this work properly we would have to provide an abstract config class, but we can only do that in myfaces-impl. However I think it's not a good idea to require myfaces-impl beeing a compile-dependency, impl should always be a runtime-dependency.
Although I really like the idea of having a typesafe way of doing configuration, I think we can't/shouln't do this for MyFaces 2.0.x because of the aforementioned reasons. However we could raise a spec issue and ask the EG to think about it. Maybe we will get a javax.faces.config.AbstractConfig for 2.x. Regards, Jakob 2010/8/11 Gerhard <[email protected]> > i would prefer something like [1] > > it allows > - a default implementation which could implement the mentioned behavior > - a typesafe config > > regards, > gerhard > > [1] http://home.base.be/vt692569/blogs/2010-07-13.html > > http://www.irian.at > > Your JSF powerhouse - > JSF Consulting, Development and > Courses in English and German > > Professional Support for Apache MyFaces > > > 2010/8/11 Matthias Wessendorf <[email protected]> > > On Wed, Aug 11, 2010 at 4:23 PM, Jakob Korherr <[email protected]> >> wrote: >> > Hi guys, >> > >> > Talking to some users of MyFaces, we found out that it would be really >> nice >> > to be able to have web.xml-settings depending on the current project >> stage. >> > For example you want to have different error pages for Development and >> > Production. >> > >> > Imagine there is the config parameter org.apache.myfaces.MY_PARAM. Now >> you >> > want to use 3 different values for this parameter, depending on the >> project >> > stage. So you can set org.apache.myfaces.MY_PARAM.DEVELOPMENT for the >> > development value, org.apache.myfaces.MY_PARAM.PRODUCTION for the >> production >> > value and org.apache.myfaces.MY_PARAM for the default value (all other >> > stages). >> >> I kinda like this fluent extension proposal. >> >> > >> > To accomplish this we could introduce a web.xml-settings manager, which >> > handles this lookup. With the help of this manager we could get rid of >> the >> > usual "lookup" via ExternalContext and use the manager instead. >> >> good idea. I hate the fact that you see over and over again the same >> calls. >> A unified "manager" that does that for you; and you just give it the param >> would be nice. >> >> > >> > What do you think? >> > >> > Regards, >> > Jakob >> > >> > -- >> > Jakob Korherr >> > >> > blog: http://www.jakobk.com >> > twitter: http://twitter.com/jakobkorherr >> > work: http://www.irian.at >> > >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> > > -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
