Your best bet is likely to store the entire WOComponent as an ivar in the session. You can get it from context().page()
That way wen they return and the session is still alive you can return that ivar to render where they were and what they were doing. So you’ll need to store it in the session in something like the end of appendToResponse() and then maybe have a link in the top left corner to “restore prior page" > On May 17, 2024, at 4:56 PM, Amedeo Mantica via Webobjects-dev > <webobjects-dev@lists.apple.com> wrote: > > I no longer use WO but I recall this framework in wonder: > ERPersistentSessionStorage > > Amedeo > > >> On 17 May 2024, at 22:01, Martino Limido via Webobjects-dev >> <webobjects-dev@lists.apple.com <mailto:webobjects-dev@lists.apple.com>> >> wrote: >> >> Hi there, >> >> it’s important to note that the `WOContext` object in WebObjects ends with >> the lifecycle of the request and response. This means that simply storing >> the `WOContext` object is not feasible as it will no longer be available >> after the request is completed. >> >> ### Possibility of Implementation: >> >> 1. **Context Serialization**: >> - While WebObjects does not natively support serializing the entire >> `WOContext`, it is possible to manually serialize the essential parts of the >> context. This includes capturing the state of components, user inputs, and >> any relevant session information. >> - You can use `context().clone()` in `Session.sleep()` to clone the context >> state. However, ensure that all referenced objects within the context are >> serializable. This might involve customizing the serialization process for >> complex objects. >> >> 2. **State Storage**: >> - Store the serialized state in a persistent format, such as a database or >> a session file. The storage mechanism should be robust enough to handle the >> complexity of the serialized data and ensure it can be accurately retrieved >> later. >> >> 3. **State Restoration**: >> - In the `restorePreviousAction` DirectAction, implement a mechanism to >> deserialize and reintegrate the previously saved state. This involves >> reconstructing the `WOContext` and ensuring all components and user states >> are accurately restored. >> - This might require a custom deserialization logic to handle complex >> objects and ensure they are correctly linked within the session. >> >> ### Challenges: >> - **Complexity**: Serializing complex objects and managing cross-references >> can significantly increase code complexity. WebObjects' inherent >> statefulness and deep object graph make this particularly challenging. >> - **Data Integrity**: Ensuring data consistency during the serialization and >> deserialization process is critical. Any mismatch can lead to errors or >> inconsistent application states. >> - **Performance**: Serialization and deserialization can impact performance, >> especially if the context is large or complex. It’s important to optimize >> this process to minimize the performance overhead. >> >> ### Recommendation: >> Given the complexities and potential issues with this approach, it might be >> better to rethink the application design. Consider structuring the >> application to use DirectActions with simpler states that are easier to >> restore. This could involve: >> - Breaking down complex states into smaller, more manageable parts that can >> be easily serialized and deserialized. >> - Ensuring that each DirectAction has a well-defined and minimal state that >> can be captured and restored without requiring the entire context. >> - Leveraging stateless designs where possible, and using session storage >> judiciously to maintain essential state information. >> >> ### Conclusion: >> Implementing this functionality is technically possible but requires >> significant effort and a deep understanding of the object lifecycle in >> WebObjects. Given that the `WOContext` object ends with the request/response >> cycle, manually serializing and restoring its state is complex and >> potentially error-prone. >> >> >> Best regards, >> Martino >> >>> Il giorno 17 mag 2024, alle ore 21:00, webobjects-dev- >>> >>> 1. re/store context somehow? (OCsite) >>> >>> >>> ---------------------------------------------------------------------- >>> >>> Message: 1 >>> Date: Thu, 16 May 2024 21:14:39 +0200 >>> From: OCsite <o...@ocs.cz> >>> To: OCsite via Webobjects-dev <webobjects-dev@lists.apple.com> >>> Subject: re/store context somehow? >>> Message-ID: <1d450aeb-ded8-4b1a-8438-59039f31b...@ocs.cz> >>> Content-Type: text/plain; charset="utf-8" >>> >>> Hi there, >>> >>> my client made a somewhat weird request: wants me to store ?the last >>> context the user worked in? in his session, and restore it when the user >>> comes to the application through a specific Direct Action (and the session >>> still lives). >>> >>> In other words, suppose the user works in the app for awhile, and then >>> closes his browser, remembering just the session ID, nothing else. >>> >>> Next thing he does, he opens >>> .../OurApp.woa/wa/restorePrevious?wosid=prevSessionID ? and wow, he finds >>> the browser window in precisely the same state it was when he closed the >>> browser some time ago. (Far as possible of course, let's assume for >>> simplicity the internal app/session/DB state did not change meantime.) >>> >>> I guess most probably I need to save context().clone() into session each >>> time in Session.sleep(), that's not difficult. But then in my >>> DirectAction.restorePreviousAction I need to resurrect the saved context >>> somehow, but I can't find a way to do that. Does anybody know how to? >>> >>> Thanks! >> _______________________________________________ >> Do not post admin requests to the list. They will be ignored. >> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) >> Help/Unsubscribe/Update your Subscription: >> https://lists.apple.com/mailman/options/webobjects-dev/amedeomantica%40me.com >> >> <https://lists.apple.com/mailman/options/webobjects-dev/amedeomantica%40me.com> >> >> This email sent to amedeomant...@me.com <mailto:amedeomant...@me.com> > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list (Webobjects-dev@lists.apple.com > <mailto:Webobjects-dev@lists.apple.com>) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/webobjects-dev/aaron%40chatnbike.com > <https://lists.apple.com/mailman/options/webobjects-dev/aaron%40chatnbike.com> > > This email sent to aa...@chatnbike.com <mailto:aa...@chatnbike.com>
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
