[dancer-users] Before Hook hit multiple times.

[Mr. Puneet Kishor]

On Jan 3, 2013, at 2:46 AM, Alexis Sukrieh <sukria at sukria.net> wrote:

>> 
>>>> While the above explanation makes sense, and understanding it can lead
>>> to
>>>>> designing applications better, my gut feeling is with Rick. If I
>>> create a
>>>>> 'before' hook, I want it normally to fire once everything the human
>>> user makes a
>>>>> request even though under the scene the browser is making multiple
>>> requests. In
>>>>> other words, the current behavior seems to be against the DWIM nature
>>> that I
>>>>> would expect.
>>> 
>> 
> I don't think I would agree here. Let me elaborate on my point of view:
> 
> Dancer is a DSL to write a web application. Its purpose is to provide a
> clean and intuitive syntax for describing how to handle a request and which
> response to produce. This is based of course on the HTTP protocol, and
> Dancer relies entirely on that.
> 
> That means that everything in Dancer's point of view is related to an
> incoming _request_. In the HTTP meaning. If Chrome hits favicon.ico
> whenever you hit the app, you'll send 2 requests every time you hit the
> browser's reload button. You are sending 2 requests, period.
> 
> Dancer sees 2 requests, and acts accordingly.
> 
> Implementing a workaround to simulate the concept of "human requests"
> versus real "HTTP requests" sounds crazy to me and error-prone.
> 
> What makes Dancer so appealing is its thin layer over the HTTP stack, this
> kind of change or enhancement is dangerous, I think.
> 
> I'm sorry if I'm not following you on this one, I hope you see my point of
> view :)
> 

I see your point completely, and as I acknowledged in my first email, I saw the point as made by David. Yet, I respectfully disagree with the above explanation. All manner of rational explanations can be put forward, but my point is, as much as possible, programming tools should allow human beings to think the way humans think, not force humans to think some other way.

HTTP was invented with documents in mind. Statelessness was a feature, and it allowed the web to rapidly scale. However, the web has gone way beyond its original intent, and most everyone is making apps that mimic some level of "app" functionality, that is, trying their best to remember state.

Dancer could have several different philosophies -- one, as you describe above, is to enable users to do things the right way. The other, as I describe, is to enable users to do the right thing even if it is the "wrong" way.

A user on a web app, as opposed to a user or a program on a command line app or a program, querying a web server is typically doing something -- clicking on a DOM object or choosing something in a form or hovering the mouse over something -- and something is happening in return. Whether that something happens on the client or server, once or many times, none of that matters from the user's point of view. Dancer is involved *if* the server is involved. So, from the POV of the app developer, she has to make the app respond rationally and reasonably in response to the user. Making that easy would be very nice to the extent that Dancer can make it easy.

As I said in my earlier post, a way would be to perhaps have two kinds of before hooks. One, that behaves the way it behaves currently, perhaps the right way, that is, firing before *every* request no matter who makes that. Two, that behaves *once* and only once in response to the app from the user's perspective. If the second way doesn't exist then users will try to code that. All I am saying is that that coding could be standardized and made available out of the box.

Nevertheless, Dancer is great, and I am happy to understand the difference elaborated above. Now that I am aware of it, I will find a way to code around it. But, I appreciate the opportunity to express my POV above.

Many thanks,

--
Puneet Kishor