Re: Data Sharing with InlineFrame Pages
Hi Dan, I don't have time to investigate deeper your application but here are the common recommendations: - don't share components between pages - share their models. even better - share just pointers which will be used by the models to find the data Martin On Fri, Dec 3, 2010 at 3:28 AM, Dan Retzlaff dretzl...@gmail.com wrote: I tracked down the gotcha and assembled the attached quickstart project to demonstrate it. Can someone please clarify whether this is a bug or an intentional design limitation? It's definitely unintuitive for those unfamiliar with Wicket's page serialization tricks. In my case, the issue manifests itself when the Page within an InlineFrame (call it InlinePage) has a reference to a component in the outer Page (call it HomePage). After InlinePage handles a request, it gets serialized into a page map entry along with the referenced component within HomePage, and HomePage's PageHolder. But HomePage gets serialized separately, and includes *its own copy* of the referenced component. Ultimately this manifests as a corrupt object graph where a component's parent does not contain the component itself [i.e. getParent().get(getId()) is null]. I believe this issue did not occur in one of the two uses I describe below because SecondLevelCachePageMap keeps a deserialized copy of the most recently accessed Page, averting the corruption that occurs in the serialization roundtrip. I have not actually verified this however. Much care and thought has obviously gone into handling multiple pages in a single request, but given this use case's (subtle) failure, I'm left wondering when it is appropriate. It seems like the only safe ways to share data bidirectionally between pages are (1) through a model that maintains the value outside of the session/page map, or (2) through AJAX callbacks via the client browser. True? Dan On Wed, Dec 1, 2010 at 6:22 PM, Dan Retzlaff dretzl...@gmail.com wrote: Hello, I have a page with an embedded InlineFrame which is used to submit a multipart form. I would like the InlineFrame's page to share a model object with the parent page. This way the parent page can control the workflow after the form is submitted. However, something is preventing model changes made during the form submission from being visible in subsequent requests to the parent page. My guess is that issue stems from the way in which the child page (with its reference to the parent page) is being serialized into the page store because the subsequent parent requests see the *unmodified * model object. Further confusing me is the fact that I use the same upload panel with the InlineFrame in two different pages, and in one of the two the model change *is* seen by the parent. I'm no PageMap expert, but I debugged into Session enough to see that the page versions are the same between the form submission request and the subsequent parent page request in both cases. There is obviously some gotcha that I've stumbled into on one page and not the other. Can anyone decipher what may be going on? Or recommend a best practice for sharing data with an embedded iframe page? I am using Wicket 1.4.13. Thanks, Dan - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Data Sharing with InlineFrame Pages
Thanks for the response, Martin. I'm with you on lack of free time. :) Using a model is not sufficient. The gotcha is that it's very important where that model lives in the component graph. If both pages hold a reference to the model, then serialization/deserialization causes the object aliasing problem demonstrated in my quickstart. The only solution compatible with Wicket's serialization logic (other than a model that points outside of Wicket) is for a single page to own the model, and for the other page to access the model through a public getter on the first. This requirement is only obvious to me after spending a day in Wicket's serialization code. I'd say it's gotcha wikihttps://cwiki.apache.org/WICKET/best-practices-and-gotchas.html#BestPracticesandGotchas-Gotchasworthy, but maybe sharing data between pages with session-backed models is relatively uncommon. As an aside, it's amazing that this page serialization stuff has been so transparent to me until now. Nice work, Wicket devs! Dan On Fri, Dec 3, 2010 at 12:40 AM, Martin Grigorov mgrigo...@apache.orgwrote: Hi Dan, I don't have time to investigate deeper your application but here are the common recommendations: - don't share components between pages - share their models. even better - share just pointers which will be used by the models to find the data Martin On Fri, Dec 3, 2010 at 3:28 AM, Dan Retzlaff dretzl...@gmail.com wrote: I tracked down the gotcha and assembled the attached quickstart project to demonstrate it. Can someone please clarify whether this is a bug or an intentional design limitation? It's definitely unintuitive for those unfamiliar with Wicket's page serialization tricks. In my case, the issue manifests itself when the Page within an InlineFrame (call it InlinePage) has a reference to a component in the outer Page (call it HomePage). After InlinePage handles a request, it gets serialized into a page map entry along with the referenced component within HomePage, and HomePage's PageHolder. But HomePage gets serialized separately, and includes *its own copy* of the referenced component. Ultimately this manifests as a corrupt object graph where a component's parent does not contain the component itself [i.e. getParent().get(getId()) is null]. I believe this issue did not occur in one of the two uses I describe below because SecondLevelCachePageMap keeps a deserialized copy of the most recently accessed Page, averting the corruption that occurs in the serialization roundtrip. I have not actually verified this however. Much care and thought has obviously gone into handling multiple pages in a single request, but given this use case's (subtle) failure, I'm left wondering when it is appropriate. It seems like the only safe ways to share data bidirectionally between pages are (1) through a model that maintains the value outside of the session/page map, or (2) through AJAX callbacks via the client browser. True? Dan On Wed, Dec 1, 2010 at 6:22 PM, Dan Retzlaff dretzl...@gmail.com wrote: Hello, I have a page with an embedded InlineFrame which is used to submit a multipart form. I would like the InlineFrame's page to share a model object with the parent page. This way the parent page can control the workflow after the form is submitted. However, something is preventing model changes made during the form submission from being visible in subsequent requests to the parent page. My guess is that issue stems from the way in which the child page (with its reference to the parent page) is being serialized into the page store because the subsequent parent requests see the *unmodified * model object. Further confusing me is the fact that I use the same upload panel with the InlineFrame in two different pages, and in one of the two the model change *is* seen by the parent. I'm no PageMap expert, but I debugged into Session enough to see that the page versions are the same between the form submission request and the subsequent parent page request in both cases. There is obviously some gotcha that I've stumbled into on one page and not the other. Can anyone decipher what may be going on? Or recommend a best practice for sharing data with an embedded iframe page? I am using Wicket 1.4.13. Thanks, Dan - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Data Sharing with InlineFrame Pages
Hello, I have a page with an embedded InlineFrame which is used to submit a multipart form. I would like the InlineFrame's page to share a model object with the parent page. This way the parent page can control the workflow after the form is submitted. However, something is preventing model changes made during the form submission from being visible in subsequent requests to the parent page. My guess is that issue stems from the way in which the child page (with its reference to the parent page) is being serialized into the page store because the subsequent parent requests see the *unmodified*model object. Further confusing me is the fact that I use the same upload panel with the InlineFrame in two different pages, and in one of the two the model change * is* seen by the parent. I'm no PageMap expert, but I debugged into Session enough to see that the page versions are the same between the form submission request and the subsequent parent page request in both cases. There is obviously some gotcha that I've stumbled into on one page and not the other. Can anyone decipher what may be going on? Or recommend a best practice for sharing data with an embedded iframe page? I am using Wicket 1.4.13. Thanks, Dan
