Also +1, but when we rename the old parameters, let's generate an error in the logs stating that the parameter name has changed, so the user has something to work with. Since we haven't made a public release yet with them, I don't think we need to temporarily allow the old parameter names to continue to be parsed -- a log entry should be good enough. We can remove the warnings after the release.
On 4/3/06, Dennis Byrne <[EMAIL PROTECTED]> wrote: > +1 ( and both examples are from me ) > > It's good that you brought this up now because both of those parameters ( and > three of four more) were introduced *after* the last release. Had these > ended up in the 1.1.2 release, I would bring up the backwards compatibility > argument. Any other thoughts? Any other context parameters added to the > code base? What do Struts and Tapestry do? > > Dennis Byrne > > >-----Original Message----- > >From: Mario Ivankovits [mailto:[EMAIL PROTECTED] > >Sent: Monday, April 3, 2006 01:19 AM > >To: 'MyFaces Development' > >Subject: Context configuration parameter name > > > >Hi! > > > >I dont want to be an asshole - so sorry in advance :-) -, but maybe we > >should find a standard how to name our context configuration parameter > >names. > > > >In the past we had the scheme "org.apache.myfaces.XXXXX" where XXXX is > >upper case only. > > > >Now I've seen we got some new configuration parameters named: > > > >org.apache.myfaces.validate > >and > >org.apache.myfaces.secret.cache et al > > > >which is against this naming pattern. > >If others dont think its mandatory to follow this scheme I'll be fine > >too (I wont start a war to archive it ;-) ) > >I just wanted to bring this up now, once the user use them it might be > >hard to change it. > > > >If we would like to go the lower-case pattern way, I'll propose to add > >lower-case aliases to our current names. > > > >Ciao, > >Mario > > > > > > >
