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? >