I'm not sure if anyone responded, so let me share how we deal with this.

Since a JPA entity can reference other (persistent entities), and usually does, we've tried to never, ever, serialize JPA entities. The only time where it's needed is when you have an "entity creation" workflow which spans more than a single screen.

For the cases where an entity is created using a single screen, we simply write a LDM which creates a new instance, setting defaults. Wicket then pushes all form fields to the entity on submit, and as a result we have an entity we can persist.

Other possible strategies:
- serialize the new entity inside a normal model (Model)
- pre-create new entities, and have a flag on them which indicates their workflow state (NEW, ACTIVE etc); that way you can simply load them through whatever EntityDatabaseModel you have in place

Met vriendelijke groet,
Kind regards,

Bas Gooren

Op 7-12-2012 19:14, schreef Nick Pratt:
Im looking for recommendations on how to work with Form data and a
JPA/Hibernate model, specifically around creating and editing domain data.

I have a JPA backed domain model, and I want to create a page/panel/form
that allows entry of a new "Foo", as well as being able to pass an existing
LDM<Foo> to the Page/Panel so that I can edit it.

Obviously I'd like to use an IModel for the domain object so that I dont
end up serializing the DB in to the session, but at the same time, I cant
use an LDM until the new entity is saved and an ID is assigned to the

For the 'new' case, do you just serialize the domain entity in to the
session, IModel<Foo> model = Model.of( new Foo() ); and let the Foo object
be serialized until such time as the is set so you can switch out
the IModel ref to an LDM? Or is it best to just show the minimal number of
fields required (*) to create a new Foo (accessed via PropertyModel(this,
"attributeName), save it, and then set the LDM<Foo> reference in the page
and then let the other form elements be shown? (This approach duplicates
code - the fields in the domain object are duplicated as primitives in the
Page (which get serialized in to the session) )

The edit functionality needs to allow all fields to be edited (including
the fields mentioned in (*) above) - I dont want to duplicate form markup
and code - once for the 'new' case and once for the 'edit' case - the
'edit' case would have a lot more fields that could be entered/edited.

Are there other approaches that I'm missing, and what is the best pattern
to follow here?

Reply via email to