Maintaining state

[448191]

I'm thinking about further maintaining state of applications by using the session array to store environmental information objects within a session.

For me, I guess this would only be sensible for my 'Client' object, which holds information about the clients capabilites and characteristics, which now won't be reassessed (avoiding some logic, potentional performance increase). This is the only object that is dependant of the user session.

Currently I use a session variable called 'applicationState' which, you guessed it, holds a sting representing the previous state of the application.

I feel I should let the 'Client' class handle setting and fetching session variables, it seems appropiate. Meaning $_SESSION['applicationState'] = $someRoute; would have to make way for $client->setState($someRoute); I don't think you should store anything that not directly relates to the client in the session array anyway.

There actually was a question when I started writing this, but after a redraft or ten, it would seem I have it all figured out... :P :P

Comments very much welcome.

[448191]

I'm confusing 'state' with 'route', pardon me.  :P

$client->setRoute($someRoute); //Would add string reference to session data, referring to the route that was used at the time of executing this statement.

[Jenk]

Only time I have found that useful is for debugging and problem tracking (creating a stack trace of the users last 10 actions)

[448191]

[quote author=Jenk link=topic=108767.msg438564#msg438564 date=1158826887]
Only time I have found that useful is for debugging and problem tracking (creating a stack trace of the users last 10 actions)
[/quote]

The is a new reason to store the previous route. Ajax.

When the client requests a refresh, the server has to know what route it should serve, otherwise it would deduct the route from the uri, effectively returing to the view of the last full page generation.

[Jenk]

I solve that diffferently, either with page.php?ajax=yes&foo=bar or by using a different action entirely.

[448191]

[quote author=Jenk link=topic=108767.msg438570#msg438570 date=1158827932]
I solve that diffferently, either with page.php?ajax=yes&foo=bar or by using a different action entirely.
[/quote]

I might be missing something here, but I don't see how that would work for page refreshes.

1) View by page.php?ajax=yes&foo=bar is served.
2) Some change is initiated by javascript.
3) Hash is added to uri, to allow for bookmarking.
4) View is changed by way of XmlHttpRequest, requesting page2.php?bar=foo
5) User presses refresh button.
6) page.php?ajax=yes&foo=bar (no hash, that isn't passed to the server) is requested from the server.
7) The view from step 1 is served again.

[Jenk]

The actual page the user is viewing:

page.php?foo=bar

the XmlHttpRequest uri: page.php?ajax=yes&foo=bar

therefore when the user refreshes, it will refresh page.php?foo=bar and not ajax=yes

[448191]

[quote author=Jenk link=topic=108767.msg438580#msg438580 date=1158828826]
The actual page the user is viewing:

page.php?foo=bar

the XmlHttpRequest uri: page.php?ajax=yes&foo=bar

therefore when the user refreshes, it will refresh page.php?foo=bar and not ajax=yes
[/quote]

Ah, I see. That's pretty smart. I was using a separate accesspoint for Ajax requests, but this makes a lot more sense, thanks.

[Jenk]

It is a seperate access point to an extent, but instead of a different page it's just a different action for the controller to execute.