ev0l wrote:
Of the framework or of the application. Applications that have to deal with low level HTTP stuff are going to be a lot more complicated, harder to maintain, and more difficult to reuse.
Abstractions hide details. This is good, if you don't need the details, but if you occasionally do, they becomes a burden, rather than a help.
ev0l wrote:
Clicking the back button in Phaux will never submit a form again or do an action twice.
Using redirect-after-post is a quite practical pattern, which I use myself, even if it means I need to use (temporary) server side state.
'do an action twice' is only an issue, if your GET requests aren't idempotent, as they should be. That's slightly off topic though, since that doesn't really have anything to do with statefulness.
ev0l wrote:
You register any values you want the back button to follow. See WHRegisteredCounter or WHNavigation. Notice registerObjectOnKeyPath.
I'm not sure I completely grasp the registerObjectOnKeyPath() function. Is it correct, that you keep the history of the entire session at the server side? Each new page will then get a new state-id?
ev0l wrote:
You can add meaningful get vars to the URL by overwriting updateRoot in your subclass of WHComponent.
And then, you would have a stateless application. That's exactly what I have been suggesting all along.
But why make the stateful solution the default, and require the user to go through a lot of work to get a stateless application, rather than the other way around?
ev0l wrote:
Works fine. Just register any value you want to follow the back button like the tabs do in WHNavigation.
OK, let's take a use-case scenario, which illustrates my concerns.
Assume that you have a page with search results, that paginates the results. You open up the same page in two tabs. In the first tab, you make a search for something. In the other tab, you make a search for something else. On tab #1, you click to page 2. Will you not see page 2 of the second search, even though you would expect page 2 of the first search?
ev0l wrote:
What happens when your state gets complex. Say you are writing an airline reservation system. The data quickly starts getting to large to store in the GET/POST vars.
There are occasions, where server side state is the most practical solution. A shopping cart for example, or a very complex form, which needs to be broken down into a multi-page form. Or keeping form values, when doing redirect-after-post. I'll use it in these cases, but I wouldn't default to use it.
Hockey wrote:I'm missing something, in regards to the PHP being responsible for persisting state...
How do you keep state? Using SESSIONS is the only way to go or some other server side mechanism anyways...
You have two ways. Either you use cookies, or you embed the state in the URL.
Hockey wrote:Relying on cookies is just crazy...what happens if the client doesn't support cookies? Users can't login?
Use www-authentication.