Create/Edit domain object data

[Nick Pratt <nb...@gmail.com>]

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

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

Re: Create/Edit domain object data

[Nick Pratt <nb...@gmail.com>]

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 <nb...@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
> 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
> object.
>
> 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 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 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?
>
>

Re: Create/Edit domain object data

[Bas Gooren <ba...@iswd.nl>]

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