On Thu, 14 Jul 2016 08:09:37 -0600 Warren Young <wyml@etr-usa.com> wrote:
On Jul 12, 2016, at 5:08 PM, WK <wanradt@gmail.com> wrote:
2016-07-12 20:54 GMT+03:00 Warren Young <wyml@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