On 7/12/2016 3:36 PM, Warren Young wrote: > On Jul 12, 2016, at 3:15 PM, John J. McDermott, CPLP <[email protected]> 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.: > > http://fsharp.org/ OK. Will. > >>> 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. Ummm, I didn't mention SQL. BUT, sometimes software has to interact with the work of others. > (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. Agreed! >> 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. Precisely. I should have included the example in my first message to avoid confusion. Sorry. > I still prefer /api, since I don’t see any particular reason to declare that > I’m using a DBMS, but please yourself. That was only an example. It could be a physical system or other data source. I chose a db to make it easier to discuss. /api is fine. The point is (and that's why I suggested ignoring the names), is that I want two behaviors with one hostname and different routes. Based on your comment above, you see that as two names, so I understand your point. I think we agree on substance. >> 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 don't want that, I just wanted to clarify. > (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.) Yes, on the same (virtual) host. I was just trying to clarify, as I noted. >>> 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. Well, I've worked with Angular. I don't really like it. I could use a client framework, but the data I used in a real implementation of this didn't need a complex framework (I used datatables.js).
--john > _______________________________________________ > dancer-users mailing list > [email protected] > http://lists.preshweb.co.uk/mailman/listinfo/dancer-users -- 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
