Jump to content

Maintaining state


448191

Recommended Posts

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.
Link to comment
Share on other sites

[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.
Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.