[dancer-users] Methods Of retrieving request parameters

Warren Young wyml at etr-usa.com
Tue Jul 12 22:36:22 BST 2016

On Jul 12, 2016, at 3:15 PM, John J. McDermott, CPLP <jjm at jkintl.com> wrote:
>> Do you know a strong functional programming language?
> Yeah. I haven't found them valuable for "production" software, but I have used them.

Take a look at F#.  It’s OCaml with the sharp corners and ugly bits knocked off.  Either of those is more accessible than Erlang or Haskell.

If its Microsoft origin bothers you, it’s completely open source, and runs just fine on OS X, Linux, FreeBSD, etc.:


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

That’s easy to say, but up-thread you were talking about DBMSes.  Except for SELECT and some of the built-in function calls, a SQL DBMS is nothing but side-effects.

(It amuses me when people talk about Erlang as a “pure” FP language when it ships with Mnesia, a disk-backed in-RAM DBMS, which amounts to a global variable store.  Talk about side-effects!)

Therefore, we practical software developers should not talk about eliminating side-effects, as the ivory tower types like to do, but instead talk about carefully walling off the places in our code where that happens, so that we can predict from the outside where such a thing is likely to occur.

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

But you do have different names, which is good.  Instead of /api as I was suggesting, you have segregated the JSON/DBMS stuff under /db.

I still prefer /api, since I don’t see any particular reason to declare that I’m using a DBMS, but please yourself.

> Are you suggesting I need (ignoring the actual names) www.mysite.com and json.mysite.com?

You could do that, too, though I’m not immediately clear on how you’d integrate name-based virtual hosting with Dancer.

(I’m assuming you meant both of those to resolve to the same host.  If not, then you’re talking about distributed computing, which adds a further layer of complexity.)

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

I think you might want to look at Angular and other SPA frameworks, then.

More information about the dancer-users mailing list