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: dretzl...@gmail.com
> To: users@wicket.apache.org
>
> 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 <j_holt5...@msn.com> wrote:
>
> >
> > I'm new to Java and Wicket. My only previous experince with web
> > applications has been with Asp.net 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 = ...build 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?
> >
