[dancer-users] Methods Of retrieving request parameters

[John J. McDermott, CPLP]

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
processes.

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?

--john


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
forward.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.preshweb.co.uk/pipermail/dancer-users/attachments/20160712/02322f4b/attachment.html>