On 7/12/2016 2:27 PM, Warren Young wrote:
> On Jul 12, 2016, at 1:41 PM, John J. McDermott, CPLP <[email protected]> wrote:
>> 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.
> Perfectly fine so far.
>
>> 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.
> Do you know a strong functional programming language? I don’t mean FP in the
> way that JavaScript is a Scheme dialect and therefore FP, or even in the way
> that Perl is FP as laid out in Dominus’ “Higher-Order Perl.” I mean FP as in
> Haskell, the ML family, Erlang, etc.
Yeah. I haven't found them valuable for "production" software, but I
have used them.
> These languages teach you the value of thinking of functions in the
> mathematical sense, which is that any function called with a given set of
> arguments should always return the same result. Another way of saying the
> same thing is that functions should not have side effects.
I completely agree. I detest side-effects.
> It is impossible to avoid all side effects in any practical program not doing
> pure mathematics, but we can minimize and restrict the scope of these side
> effects by thinking hard about where the boundaries should be. Strong FP
> languages sensitize you to this way of thinking.
>
> In the context of this debate, the principles of tightly-scoped side effects
> and referential transparency tell us that if you should not have a a Dancer
> route that returns HTML in one context and JSON in another. Either the route
> must differ somehow or the parameters must differ.
Ohhh, I hate to call it a "debate". I'm trying to look at "best
practices", particularly focusing on ease-of-use in different scenarios.
I do not want one route to return different things in different
contexts, per se, so perhaps I was unclear. I want:
www.mysite.com to behave in a way that a user would expect a website to
behave: forms, nice view, etc.
www.mysite.com/db/table1 or whatever to behave in a manner a JSON user
would expect. I don't want different names. Are you suggesting I need
(ignoring the actual names) www.mysite.com and json.mysite.com?
> My preference is to put all JSON-returning Dancer routes under /api, then
> make all other routes return HTML. (That’s a simplification. My current app
> also has /pdf for the routes that return dynamically-generated PDFs, for
> example.)
This is what I suggested above, I think.
> Where the HTML-returning routes need data returned by the JSON API, either:
>
> 1. Call the internal JSON-returning route handler from the HTML route handler
> and use its data to construct the HTML; or
>
> 2. Call back into the API from the client side via JS and construct HTML from
> the returned JSON data there.
>
> An example of alternative 1 is:
>
> sub getSomeData { … used below … }
>
> get '/foo' => { # because not under /api, returns HTML
> # Do stuff here
> # ...
>
> # Okay, we’re ready to return our page
> return template '/foo' => {
> oneElement => getSomeData(param 'bar'),
> anotherElement => $variableComputedAbove,
> }
> };
>
> prefix '/api' => {
> prefix '/some' => {
> get '/data' => \&getSomeData
> };
> };
I have done this in real life.
> Here we have two routes, one returning HTML and one returning JSON, the first
> of which is implemented in terms of the second. Because of Dancer's
> automatic serializers, getSomeData() can return a normal Perl data structure
> that can either be consumed directly by the template used in the HTML case or
> be serialized to JSON for consumption on the client side via JS code.
>
> Note the use of code references here to allow the HTML route handler to call
> the JSON route handler.
>
> You can read more about this style of development in a series of articles I
> wrote for the fizzled Dancer 2015 Advent Calendar:
>
> https://goo.gl/u900Ii
>
> A lesser design principle is that, to the greatest extent practical, you
> should push most of the code into the JSON side to reduce code duplication.
> The HTML/JS client-side code can also consume JSON, but the JSON API has
> little use for HTML.
Agreed/
>
> To drag this back onto the topic of this particular thread, it is immaterial
> in my view whether the values passed to the Dancer route come from the URL’s
> query parameters, are defined as part of the route, or are passed in via a
> POST call in the request body. Parameters are parameters, and a
> properly-written Dancer route handler should return the same data regardless
> of the exact mechanism used to pass those parameters.
Hmmm. I don't want the HTML page to have to be JSON. I want a more
conventional form use (although it could be JSON).
--john
--
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.
_______________________________________________
dancer-users mailing list
[email protected]
http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
