Re: Context configuration parameter name

2006-04-03 Thread Craig McClanahan
On 4/2/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?
Struts tends to use org.apache.struts.XXX (upper case final portion) for both context init parameters and attribute keys), but it's not universal. Same with JSF (javax.faces.).
Personally, I can't see this issue being a useful place to become pedantic :-). There are much more important usability issues that deserve attention.
Dennis ByrneCraig-Original Message-
From: Mario Ivankovits [mailto:[EMAIL PROTECTED]]Sent: Monday, April 3, 2006 01:19 AMTo: 'MyFaces Development'Subject: Context configuration parameter name
Hi!I dont want to be an asshole - so sorry in advance :-) -, but maybe weshould find a standard how to name our context configuration parameternames.In the past we had the scheme 
org.apache.myfaces.X where  isupper case only.Now I've seen we got some new configuration parameters named:org.apache.myfaces.validateandorg.apache.myfaces.secret.cache
 et alwhich is against this naming pattern.If others dont think its mandatory to follow this scheme I'll be finetoo (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 wouldlike to go the lower-case pattern way, I'll propose to addlower-case aliases to our current names.Ciao,Mario



Re: Context configuration parameter name

2006-04-03 Thread Mario Ivankovits
Craig McClanahan wrote:
 Personally, I can't see this issue being a useful place to become
 pedantic :-). 
Sure, you are right, but on the other hand this can easily be solved and
so I'll propose to change it.
It looks more professional if we have a clean way - the configuration is
one of the first things a user has to play with.
And we need a standard, e.g. we dont want to let one discard the
org.apache.myfaces. prefix - so why not also define how to write the rest.

 There are much more important usability issues that deserve attention.
A short excerpt of what you have in mind would be nice.


---
Mario



Re: Context configuration parameter name

2006-04-03 Thread Mike Kienenberger
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.X where  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
 
 





Context configuration parameter name

2006-04-02 Thread Mario Ivankovits
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.X where  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



Re: Context configuration parameter name

2006-04-02 Thread Dennis Byrne
+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.X where  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