[Dancer-users] case insensitive param keys

[sawyer x]

I'm replying to the end of the thread, but it's meant to be a reply to all.

Stephane, Mike: great research!

It appears as though we've hit a gray area in the RFC between desired
implied behavior and preferred explicit abilities.

On Thu, Oct 7, 2010 at 10:04 AM, damien krotkine <dkrotkine at gmail.com>wrote:

>
>
> On 6 October 2010 19:18, Stephane <stephane at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.backup-manager.org/pipermail/dancer-users/attachments/20101007/85ab539f/attachment.htm>