On Thu, 14 Jul 2016 08:09:37 -0600 Warren Young <[email protected]> wrote:
> On Jul 12, 2016, at 5:08 PM, WK <[email protected]> wrote: > > > > 2016-07-12 20:54 GMT+03:00 Warren Young <[email protected]>: > > > >> 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 _______________________________________________ dancer-users mailing list [email protected] http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
