On Thu, Oct 7, 2010 at 10:04 AM, damien krotkine
<dkrotkine@gmail.com> wrote:
On 6 October 2010 19:18, Stephane
<stephane@shimaore.net> wrote:
Without spending a lot more time researching, it would seem like the correct
approach is:
1) case sensitive by default
2) case insensitive by config
Agreed.
I agree we should be case sensitive by default and by explicit request we could normalize stuff.
I was going to suggest that the "params_lc" option (mentioned earlier) could be a boolean or a CODE ref so that people can do fancy transforms (including locale-dependent ones) if they'd like.
In this case, "params_lc" would be a bad name. What about "params_normalization" or something similar, that can accept either 'uppercase', 'lowercase', or a code reference?
Naming methodologies are a pet peeve of mine. I don't like long names (when they aren't necessary) and I want it to be easy to find. Unfortunately "params_lc" isn't very clear, and "params_normalization" (via Dancer::Plugin::ParameterNormalization) seems like too much.
I suggest first having the code to implement it, then deciding on a name. If the code is succinct enough, there's a chance to get it in core and not as a plugin. Generally, I would suggest integrating it if it's implemented cleanly.
Also, some people may want to normalize the params only in some part of the application. Do we want to handle that?
I don't think we should. I suggest being as straight as possible. Even though we're flexible (and that's awesome), we still want a coherent and (most importantly) a consistent behavior. If it's lowercased, it's lowercased. If it's not normalized, it's not.
S.