[dancer-users] Methods Of retrieving request parameters

John J. McDermott, CPLP jjm at jkintl.com
Tue Jul 12 20:41:20 BST 2016

Maybe I agree and maybe I don't. I'm trying to think it through and
would like comments.

Let's say I have an app that can generate two kinds of output.  It is a
front-end to a database It can be used with a JSON interface or it can
present HTML as a traditional web page. The web page uses a form for the
user to access the data. The JSON uses a GET with a path that Dancer2

I *could* add a /html element to the path to say "output as html" but it
would seldom -- if ever -- be used. I *could* add a checkbox to the web
form so it would return JSON but it is unlikely a normal person would
want that.

So is it better to always specify the output type explicitly to get a
particular behavior, or is it as good or better to have an app that
behaves differently depending on how it is invoked? The web is different
than most desktop applications as web apps can function as data servers
(e.g. with JSON) with no UI or as a web page with a UI.

What do you (all) think?


On 7/12/2016 11:54 AM, Warren Young wrote:
> On Jul 12, 2016, at 9:38 AM, Warren Young <wyml at etr-usa.com> wrote:
>> If your app is dependent on the path the data took to get to it, it is brittle.
> Clarification: If your app *behavior* changes depending on where the data comes from, it is brittle.
> I gave cat(1) as an example of doing it right.  For a more complex example, consider sqlite3.  It will accept SQL via stdin or as a parameter following the database file name.  Should it instead accept SQL via only one path?  Should its interpret the SQL differently based on the input path?  No and no.  (And for the record, I think sqlite3 should *also* accept SQL in from a named file.)

John J. McDermott, CPLP
Learning and Performance Consultant
jjm at jkintl.com 575/737-8556
Check out my security blog posts <http://cybersecurity.learningtree.com>
Add an A for the Arts To STEM and get STEAM and a strong engine to move
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.preshweb.co.uk/pipermail/dancer-users/attachments/20160712/02322f4b/attachment.html>

More information about the dancer-users mailing list