I like that idea a lot. Is there already a key associated with each window that I can use, or would I need to manually create a key and embed it on the page and repost it myself?
On Oct 16, 11:52 am, Gareth McCumskey <[email protected]> wrote: > What about creating a unique session entry per window? Something like > $this->getUser()->setAttribute($window_name.$cust_id, $default, $value); > > On Fri, Oct 16, 2009 at 12:44 PM, Mark Smith < > > > > [email protected]> wrote: > > > Ok, as a simple example currently one of my screens might select a > > customer and store this id in session. Another screen might show a > > summary of the currently selected customer and a form for associating > > an order with that customer. > > > This is a simple example, (I actually have screens showing many > > database entities in different contexts). Up until now it has been > > very convenient to stick the current entity id in session and forget > > about it, not having to worry about chaining forms and actions > > together makes it much easier to focus on designing and supporting > > multiple page flows. > > > However it all breaks the moment a user has more than one page open: > > If while that second screen is open a new customer is selected in > > another window the action will pick up the new id from session but > > when the user submits the form he/she will see the old customer and > > naturally assume that is who they are submitting the order against. > > > So I guess I'm being greedy and looking for a way to get the best of > > both worlds. (A session-like container for me to stick my current ids > > AND seperate states for each window. Any ideas? > > > Thanks > > > On Oct 16, 9:43 am, Gareth McCumskey <[email protected]> wrote: > > > Perhaps a better description of what you're after, some kind of use case > > > perhaps, might better help people to answer the question? > > > > On Fri, Oct 16, 2009 at 10:04 AM, Mark Smith < > > > > [email protected]> wrote: > > > > > Session is no good, as if the user has multiple windows open they > > > > could unintentionally interact with eachother. > > > > > I know hidden html inputs are usually the way this is done, but was > > > > hoping symfony had something that takes care of serialising and > > > > reposting these on each page load? > > > > > On Oct 16, 7:20 am, Gareth McCumskey <[email protected]> wrote: > > > > > http is a stateless protocol so no language can manage states. We > > fake > > > > > states by using session variables, cookies, etc. Symfony has loads of > > > > > session/cookie management features. > > > > > > On Thu, Oct 15, 2009 at 4:48 PM, Mark Smith < > > > > [email protected] > > > > > > > wrote: > > > > > > > Does symfony provide any mechanisms for managing page state? > > > > > > > Thanks > > > > > > -- > > > > > Gareth McCumskeyhttp://garethmccumskey.blogspot.com > > > > > twitter: @garethmcc > > > > -- > > > Gareth McCumskeyhttp://garethmccumskey.blogspot.com > > > twitter: @garethmcc > > -- > Gareth McCumskeyhttp://garethmccumskey.blogspot.com > twitter: @garethmcc --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "symfony users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/symfony-users?hl=en -~----------~----~----~----~------~----~------~--~---
