Re: re/store context somehow? (OCsite)
On 18 May 2024, at 6:26 am, Amedeo Mantica via Webobjects-dev wrote: > I no longer use WO but I recall this framework in wonder: > ERPersistentSessionStorage That framework is a fantastic proof of concept, but in practice the approach can be quite brittle. It works by Java-serializing the object graph rooted at the WOSession, so if any object in that graph isn't serializable, it's game over for that session. By all means try it out, but in our experience (and we've sunk many hours into experimentation with it), it works brilliantly right up until it fails spectacularly. -- Paul Hoadley https://logicsquad.net/ https://www.linkedin.com/company/logic-squad/ ___ 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
Re: re/store context somehow? (OCsite)
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 > 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 >> 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 >>> To: OCsite via Webobjects-dev >>> 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 >>> .
Re: re/store context somehow? (OCsite)
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 > 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 >> To: OCsite via Webobjects-dev >> 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! > ___
Re: re/store context somehow? (OCsite)
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 > To: OCsite via Webobjects-dev > 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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
