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 wiki<https://cwiki.apache.org/WICKET/best-practices-and-gotchas.html#BestPracticesandGotchas-Gotchas>worthy, 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.org>wrote: > 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 > > >
