On 03/05/2013 9:58 AM, Christian Reiter wrote:

I'm wondering what's the recommended way to store a unpersisted object while it is edited (I'm using EJBs with JPA as backend).

Let's imagine I want to build a customer editor which should be able to handle editing of new (unpersisted) and existing (persisted) customers.

If I use a loadable detachable model to load the customer from the backed, all unpersisted changes between requests are lost - not really desirable. If I use a simple model which stores the entity in serialized form my sessions are growing and in addition I've to handle entity refreshing if a user navigates back to the page by using the browser's back button to prevent the user from saving an old entity state.
I don't use JPA anymore, so this is from memory. If you store the JPA entity objects directly, you're actually storing the proxy objects created by your JPA provider to handle lazy-loading and such. This means you're probably serializing the entity manager as well! That would explain your session size issue. You can use dto (data transfer objects) instead which will not take much room in the session. This means you'll have to transfer data between the dto and the entity.

One way or another you must store the edited values between requests if the client doesn't send them back as part of a form. If using dto still makes your session size too large, you can store the temporary data in the database and keep an id pointing to that data in the session.

Best solution I can imagine would be if there would be a callback or overridable method which is called when the user navigates to a page and another one which is called when the user leaves a page. Those methods would be great to prepare and cleanup models. Are there such methods?
No method will reliably inform you that a user left a page. His WIFI could die, the power could go out, etc. You must clear all expired temporary data after some time. If your data is stored in the session, that's done automatically for you.

I hope this helps.


To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Reply via email to