Page 1 of 1

Multiple component state preservation???

Posted: Wed Jul 04, 2007 12:08 pm
by alex.barylski
Typically a web page/web site will only have a single component/system which persists state across requests, such as the pagination of a list of users.

I am at the point in my framework where I have to make the choice, do I build in native support for multiple components to persist state on a single page at a time or not.

Obviously it would be neat although I not sure entirely practical and the over head in code complexity goes against Agile for sure.

Can you think of a rock solid reason why I may want two or more components to persist state across multiple requests?

For instance, consider the possibility of having a search engine listings like Google, where I have two distinct but related listings:
a. Standard
b. Premium

It might be neat for the Standard listings to retain it s pagination state & keywords while allowing the user to page through the premium listings as well, without changing or clearing the state of the standard listings.

The implementation is complicated but for good reason, it essentially hides all those details from the component developer, basically there is no need for the component developer to have knowledge of that fact that it needs to retain state, etc, this is all handled by the framework.

So I ask, can you think of any scenarios where this would be a useful or desire functionality? Please provide examples so I can take them into consideration before begining implementation or skipping onto the next requirement.

Cheers :)

Posted: Wed Jul 04, 2007 12:12 pm
by Jenk
This was the primary cause of the entire Seaside/Phaux and now 7 page Framework thread :|

Posted: Wed Jul 04, 2007 12:32 pm
by alex.barylski
Jenk wrote:This was the primary cause of the entire Seaside/Phaux and now 7 page Framework thread :|
I've read that thread quickly and only seen a few replies even mention the idea of "continuations" but in no way do I see any specific examples as to when this might come in handy. Perhaps I should have posted in General Disscussion.

I do not care about implementation specifics. I have solved the problem conceptually. I am looking for examples of when this might come in handy.

Posted: Thu Jul 05, 2007 2:40 am
by Maugrim_The_Reaper
I produce code for a few PHP games where multiple areas of the overall application must retain state. Games, are I suppose, slightly more complex than the typical PHP app in that regard since there is a massive amount of interaction from the user and very little pause between requests. Content is minimal - limited to brief snippets of text and tables of data. It's possible to switch from component to component, and back again in a very short time so saving state can help decrease the user's frustration visiting page 5 in a paginated list by saving their pg5 location as a default for the next visit.

The solution I use is to split state data across subarrays of $_SESSION. The Zend Framework has something similar called "Session Namespaces". The idea is that whenever a specific independent component wishes to store state, via the session (other means are similarly possible but I'll assume you want $_SESSION for now) you create a new object representing only part of the $_SESSION array, e.g. $_SESSION['APP_FLEET']['lastPage'], $_SESSION['APP_MAIN']['userId'], $_SESSION['APP_AUTH']['name']

The actual $_SESSION is buried in the object, so its encapsulated - not completely since its a superglobal, but enough that your components can rely on a predictable namespace on $_SESSION across multiple requests. The object is only attached to a specific subarray of $_SESSION - it has no capability to write anywhere else on the $_SESSION array.

Posted: Thu Jul 05, 2007 3:55 am
by Jenk
Hockey wrote:
Jenk wrote:This was the primary cause of the entire Seaside/Phaux and now 7 page Framework thread :|
I've read that thread quickly and only seen a few replies even mention the idea of "continuations" but in no way do I see any specific examples as to when this might come in handy. Perhaps I should have posted in General Disscussion.

I do not care about implementation specifics. I have solved the problem conceptually. I am looking for examples of when this might come in handy.
The entire point of registerObjectForBacktracking($someObject) method in Phaux is to maintain $someObject's state at the various stages.

Posted: Thu Jul 05, 2007 2:57 pm
by alex.barylski
Maugrim_The_Reaper wrote:I produce code for a few PHP games where multiple areas of the overall application must retain state. Games, are I suppose, slightly more complex than the typical PHP app in that regard since there is a massive amount of interaction from the user and very little pause between requests. Content is minimal - limited to brief snippets of text and tables of data. It's possible to switch from component to component, and back again in a very short time so saving state can help decrease the user's frustration visiting page 5 in a paginated list by saving their pg5 location as a default for the next visit.

The solution I use is to split state data across subarrays of $_SESSION. The Zend Framework has something similar called "Session Namespaces". The idea is that whenever a specific independent component wishes to store state, via the session (other means are similarly possible but I'll assume you want $_SESSION for now) you create a new object representing only part of the $_SESSION array, e.g. $_SESSION['APP_FLEET']['lastPage'], $_SESSION['APP_MAIN']['userId'], $_SESSION['APP_AUTH']['name']

The actual $_SESSION is buried in the object, so its encapsulated - not completely since its a superglobal, but enough that your components can rely on a predictable namespace on $_SESSION across multiple requests. The object is only attached to a specific subarray of $_SESSION - it has no capability to write anywhere else on the $_SESSION array.
Hmmm...a game is not exactly (about as opposite as you can get actually) what I am developing this framework for. Business applications, particularly CMS, etc.

I'm not sure your fully understanding me, but it's hard to explain. I'm not refering to object persistence per se, but rather the interface, which relies on the objects.

Consider my example again:

You have an automotive listings page. It lists:

1) 5 premium paginated listings
2) 30 standard paginated listings

Each of the two sections are on ONE page. Each section has it's own independent pagination links (next, prev, first, last, etc)

When you paginate the premium listings ONLY the premium ads update, so if you were on page 3 of standard listings and page one of premium, when you navigate to page 2 of premium listings, standard ads stay on page 3. Usually, these ads are paginated togather or the one would loose persistence when they other gained focus.

In order for this system to work, you essentially need a way to indicate which module is capturing the attention, and to notify other modules to persist their state (likely using SESSION - it's what I used). Each module requires a unique module ID, etc, etc.

I have solved that conceptually but it will take quite a bit of work to implement. Ideally I was looking for practical/theoretical (oxymoron?) examples of when that might come in handy and/or whether it's a practical feature of a framework. The module is simply registered with the system at which point a GUID is generated and attached. The module developer is not responsible for using unqiue ID's...much like Windows messaging system. When a request is made it looks like:

Code: Select all

index.php?modid=23
Any arguments after that are then only touched and handled by by that module with that ID. In this way, only a single module may receive input at any one time, but multiple modules are capable of persisting state across requests.

Not sure where to go from here... :)

Hopefully you have a clearer idea of what it is I'm doing and may have a suggestion for improvement or better yet, examples of when that functionality might come in handy (silly question I know).

Cheers :)