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:
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
