Jump to content


Photo

Maintaining state


  • Please log in to reply
8 replies to this topic

#1 448191

448191
  • Staff Alumni
  • Advanced Member
  • 3,545 posts
  • LocationNetherlands

Posted 20 September 2006 - 11:43 AM

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.


#2 448191

448191
  • Staff Alumni
  • Advanced Member
  • 3,545 posts
  • LocationNetherlands

Posted 21 September 2006 - 08:15 AM

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.

#3 Jenk

Jenk
  • Members
  • PipPipPip
  • Advanced Member
  • 778 posts

Posted 21 September 2006 - 08:21 AM

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

#4 448191

448191
  • Staff Alumni
  • Advanced Member
  • 3,545 posts
  • LocationNetherlands

Posted 21 September 2006 - 08:29 AM

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


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.

#5 Jenk

Jenk
  • Members
  • PipPipPip
  • Advanced Member
  • 778 posts

Posted 21 September 2006 - 08:38 AM

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

#6 448191

448191
  • Staff Alumni
  • Advanced Member
  • 3,545 posts
  • LocationNetherlands

Posted 21 September 2006 - 08:49 AM

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


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.



#7 Jenk

Jenk
  • Members
  • PipPipPip
  • Advanced Member
  • 778 posts

Posted 21 September 2006 - 08:53 AM

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

#8 448191

448191
  • Staff Alumni
  • Advanced Member
  • 3,545 posts
  • LocationNetherlands

Posted 21 September 2006 - 09:00 AM

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


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



#9 Jenk

Jenk
  • Members
  • PipPipPip
  • Advanced Member
  • 778 posts

Posted 21 September 2006 - 09:40 AM

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.




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users