[dancer-users] Methods Of retrieving request parameters

[Chad Wallace]

On Thu, 14 Jul 2016 08:09:37 -0600
Warren Young <wyml at etr-usa.com> wrote:

> On Jul 12, 2016, at 5:08 PM, WK <wanradt at gmail.com> wrote:
> > 
> > 2016-07-12 20:54 GMT+03:00 Warren Young <wyml at etr-usa.com>:
> > 
> >> I gave cat(1) as an example of doing it right.  For a more complex
> >> example, consider sqlite3.
> > 
> > Should sqlite3 (or cat) accept all three paths same time?
> 
> Of course not, and they don’t, any more than Dancer’s params()
> mooshes all three together:
> 
>    $ echo foo | cat <(echo bar)
>    bar
>    $ echo 'select 2*3' | sqlite3 x.db 'select 3*4'
>    12

But Isn't that what parameters() does now with Hash::MultiValue?
So for the example given below, parameters()->get_all('id') would return
( 123, 223, 333 ), right?  Or maybe ( 223, 333, 123 ).

While it is more complex now (having half a dozen ways to get at the
same value), I think this is a decent thing for a framework to do.  It
gives the app developer every option to define how their app behaves,
instead of having the framework dictate things.


> > Which one should first, which last?
> 
> That's up to the Dancer designers to specify.
> 
> > Should those inputs just concatenated
> > together or should they divert each other in some order?
> 
> The three parameter sources should have a defined and documented
> precedence order.
> 
> > So POSTing path with query and form params
> > 
> > /item/id/123?id=223
> > 
> > [id=333]
> > 
> > we start with 3 different id-s, but at end we have one of them. Is
> > it good design for app? I don't think so.
> 
> You see this kind of thing a lot, do you?
> 
> If a caller does something like what you suggest, it doesn’t matter
> which one Dancer chooses to pass to your app.  The caller has made an
> ambiguous call, so it is at the mercy of Dancer’s precedence rules.

-- 

C. Chad Wallace, B.Sc.
The Lodging Company
http://www.lodgingcompany.com/
OpenPGP Public Key ID: 0x262208A0