Re: Create/Edit domain object data

2012-12-28 Thread Bas Gooren

Nick,

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
LDMFoo 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
object.

For the 'new' case, do you just serialize the domain entity in to the
session, IModelFoo model = Model.of( new Foo() ); and let the Foo object
be serialized until such time as the Foo.id 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 LDMFoo 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?





Re: Create/Edit domain object data

2012-12-07 Thread Nick Pratt
As a followup, Ive used both approaches - although we tended to wrap the
non-persisted entity inside a DomainLDM

N

On Fri, Dec 7, 2012 at 1:14 PM, Nick Pratt nbpr...@gmail.com wrote:

 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
 LDMFoo 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
 object.

 For the 'new' case, do you just serialize the domain entity in to the
 session, IModelFoo model = Model.of( new Foo() ); and let the Foo object
 be serialized until such time as the Foo.id 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 LDMFoo 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?