Thanks dretzlaff for your reponse. Indeed overriding detach elicits the 
behavior I desired. Per your warnings, I should determine if this approach is 
really more efficient. I wonder how many occasions in my programming career 
I've assumed my way is best, when the complete opposite is true...
 > Date: Fri, 4 May 2012 15:15:08 -0700
> Subject: Re: Store models short-term
> From:
> To:
> Hi, Jason. Welcome to Wicket!
> If you want to tie an entity to a page, best save the entity within the
> page itself. You can do this by using a simple o.a.w.model.Model. If you
> don't want to detach between requests, then LDM is not a good fit.
> There are use cases where serializing entities at the app level (instead of
> the database) makes sense, such as wizards where saving prematurely results
> in an invalid data model. However, if your motivation is simply performance
> then I suggest you verify your assumptions. Retrieving entities by primary
> key is generally very fast, and if it's not fast then it's because it's
> really large and you probably don't want that serialized in the session
> anyway. The "optimization" is especially moot in clusters where the
> undetached entities are replicated across the network as part of the HTTP
> session. And there are other disadvantages such as having to deal with
> detached entities, with potentially stale state.
> I'll mention one hack for which another Wicket user should rightly
> reprimand me. As I mentioned recently, Wicket keeps the most recently
> accessed page is a deserialized state to optimize serving the next request.
> All components are still detached, but if you override IModel#detach() in
> your LDM and suppress super.detach() then your entity will hang around.
> This has the behavior you describe, since (1) the entity does not need to
> be reloaded on subsequent requests, and since it's object reference is
> transient (2) it goes away as soon as another page is accessed, and (3) it
> does not get replicated among the cluster.
> Best of luck,
> Dan
> On Fri, May 4, 2012 at 2:40 PM, JASON HOLT <> wrote:
> >
> > I'm new to Java and Wicket. My only previous experince with web
> > applications has been with forms (not MVC). Please be patient;
> > coming from the postback event paradigm, I'm struggling to grasp the
> > concepts in Wicket. In my simple scenario, assume there is no AJAX. I need
> > to build the model from a database. If I use an LDM, on a postback Wicket
> > calls to the database to rebuild the model before updating it with the new
> > values. But if I don't use an LDM, Wicket will serialize the model in the
> > PageMap. I would like to keep the model 'in memory' long enough to process
> > the postback to avoid unecessary calls to the database, but release it when
> > I have moved on to a different page. I thought of something like this... In
> > the LDM  @Override
> >  public Object load()
> >  {
> >   ...somehow get the session.
> >   if (session.getAttribute("PageAModel")!=null)
> >   {
> >    return (PageAModel)session.getAttribute("PageAModel");
> >   }
> >   else
> >   {
> >    PageAModel pageAModel = from database.
> >    session.setAttribute("PageAModel", PageAModel);
> >    return pageAModel;
> >   }
> >  } Then in the Page...  @Override
> >  public void onSubmit()
> >  {
> >   PageAModel pageAModel=(PageAModel)session.getAttribute("PageAModel");
> >   ...update the database with   PageAModel pageAModel =
> > (PageAModel)ldm.getObject();
> >   ...   //removes the model from session?
> >   session.setAttribute("PageAModel")=null;
> >   this.setResponsePage(...);
> > } I suspect there is a better way to handle this. Can I avoid using an
> > LDM, but somehow remove the model from the PageMap after leaving the page?
> >

Reply via email to