You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Stephen Swinsburg <s....@lancaster.ac.uk> on 2009/02/28 19:20:16 UTC
bad practice in sharing models between wicket form and hibernate?
Hi all,
I'm after your thoughts on the following method.
Suppose there is a wicket form with some fields that can map directly
to a simple Hibernate object, and hence a db table. Is it safe to
simply wrap this object in a CompoundPropertyModel and use it as the
backing model for the form?
Then in the onSubmit method, calling a method to get the object from
the form's model and saving it via Hibernate.
This does work fine, I'm just after any pitfalls that might happen
down the track. Very simple form here.
thanks.
S
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: bad practice in sharing models between wicket form and hibernate?
Posted by Willis Blackburn <wb...@panix.com>.
Johan,
I was trying to say, in a confused kind of way, that standard practice
is to back a form up with a bean of some kind, and that replacing that
bean with a persistent object wouldn't necessarily increase memory
utilization enough to bother with a detached model. On the other hand
if the persistent object had lots of references to other objects then
maybe detaching it would be a good idea. On the other hand, if the
form uses lots of AJAX, then it might not be worth reloading the
persistent object every time a request comes in. I suppose that the
best approach depends on the requirements.
W
On Mar 1, 2009, at 9:00 AM, Johan Compagner wrote:
> i didnt say you have to have a different object.
> I just say dont keep persistent objects in memory between requests.
> Use
> detachable for that.
>
> The only exception i guess is when you create a new object that isnt
> persisted yet to the db and you have some kind of wizard to fill it
> up.
>
> On Sun, Mar 1, 2009 at 14:56, Willis Blackburn <wb...@panix.com>
> wrote:
>
>> Let's say you have a Java object with 20 fields that's mapped to a
>> database
>> using Hibernate. I don't see that there's much difference in terms
>> of
>> memory utilization between using that object as the model and
>> creating a
>> separate object with 20 fields to use as the model. Following the
>> principle
>> of not repeating yourself, I'd say that everything else being
>> equal, it
>> makes more sense to use the persistent object. Of course there
>> will always
>> be fields that you don't want to be set directly from the form, but
>> you can
>> use Brill's strategy of wrapping the persistent object in another
>> object
>> that just contains the fields for which you want to implement some
>> extra
>> logic.
>>
>> There's a subtle difference between having the model reload the
>> persistent
>> object every time and just keeping a hard reference to it that is
>> worth
>> mentioning. If you keep a hard reference to the persistent object,
>> and
>> you're using Hibernate's version or timestamp feature, and you
>> actually
>> merge the object back into the session rather than copy the fields
>> to a
>> newly-loaded object, then Hibernate will be able to detect cases in
>> which
>> the user is trying to save edits to a stale version of the object.
>> This
>> isn't always useful, but it might be, depending on your requirements.
>>
>> W
>>
>>
>>
>>
>> On Mar 1, 2009, at 5:09 AM, Johan Compagner wrote:
>>
>> You shouldnt put that object directly in a CPM, but have a loadabled
>>> detachable model in between. Because now you probably have that hib
>>> object in the page between requests
>>>
>>> On 28/02/2009, Stephen Swinsburg <s....@lancaster.ac.uk>
>>> wrote:
>>>
>>>> Hi all,
>>>>
>>>> I'm after your thoughts on the following method.
>>>>
>>>> Suppose there is a wicket form with some fields that can map
>>>> directly
>>>> to a simple Hibernate object, and hence a db table. Is it safe to
>>>> simply wrap this object in a CompoundPropertyModel and use it as
>>>> the
>>>> backing model for the form?
>>>> Then in the onSubmit method, calling a method to get the object
>>>> from
>>>> the form's model and saving it via Hibernate.
>>>>
>>>> This does work fine, I'm just after any pitfalls that might happen
>>>> down the track. Very simple form here.
>>>>
>>>> thanks.
>>>> S
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: bad practice in sharing models between wicket form and hibernate?
Posted by Johan Compagner <jc...@gmail.com>.
i didnt say you have to have a different object.
I just say dont keep persistent objects in memory between requests. Use
detachable for that.
The only exception i guess is when you create a new object that isnt
persisted yet to the db and you have some kind of wizard to fill it up.
On Sun, Mar 1, 2009 at 14:56, Willis Blackburn <wb...@panix.com> wrote:
> Let's say you have a Java object with 20 fields that's mapped to a database
> using Hibernate. I don't see that there's much difference in terms of
> memory utilization between using that object as the model and creating a
> separate object with 20 fields to use as the model. Following the principle
> of not repeating yourself, I'd say that everything else being equal, it
> makes more sense to use the persistent object. Of course there will always
> be fields that you don't want to be set directly from the form, but you can
> use Brill's strategy of wrapping the persistent object in another object
> that just contains the fields for which you want to implement some extra
> logic.
>
> There's a subtle difference between having the model reload the persistent
> object every time and just keeping a hard reference to it that is worth
> mentioning. If you keep a hard reference to the persistent object, and
> you're using Hibernate's version or timestamp feature, and you actually
> merge the object back into the session rather than copy the fields to a
> newly-loaded object, then Hibernate will be able to detect cases in which
> the user is trying to save edits to a stale version of the object. This
> isn't always useful, but it might be, depending on your requirements.
>
> W
>
>
>
>
> On Mar 1, 2009, at 5:09 AM, Johan Compagner wrote:
>
> You shouldnt put that object directly in a CPM, but have a loadabled
>> detachable model in between. Because now you probably have that hib
>> object in the page between requests
>>
>> On 28/02/2009, Stephen Swinsburg <s....@lancaster.ac.uk> wrote:
>>
>>> Hi all,
>>>
>>> I'm after your thoughts on the following method.
>>>
>>> Suppose there is a wicket form with some fields that can map directly
>>> to a simple Hibernate object, and hence a db table. Is it safe to
>>> simply wrap this object in a CompoundPropertyModel and use it as the
>>> backing model for the form?
>>> Then in the onSubmit method, calling a method to get the object from
>>> the form's model and saving it via Hibernate.
>>>
>>> This does work fine, I'm just after any pitfalls that might happen
>>> down the track. Very simple form here.
>>>
>>> thanks.
>>> S
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: bad practice in sharing models between wicket form and hibernate?
Posted by Willis Blackburn <wb...@panix.com>.
Let's say you have a Java object with 20 fields that's mapped to a
database using Hibernate. I don't see that there's much difference in
terms of memory utilization between using that object as the model and
creating a separate object with 20 fields to use as the model.
Following the principle of not repeating yourself, I'd say that
everything else being equal, it makes more sense to use the persistent
object. Of course there will always be fields that you don't want to
be set directly from the form, but you can use Brill's strategy of
wrapping the persistent object in another object that just contains
the fields for which you want to implement some extra logic.
There's a subtle difference between having the model reload the
persistent object every time and just keeping a hard reference to it
that is worth mentioning. If you keep a hard reference to the
persistent object, and you're using Hibernate's version or timestamp
feature, and you actually merge the object back into the session
rather than copy the fields to a newly-loaded object, then Hibernate
will be able to detect cases in which the user is trying to save edits
to a stale version of the object. This isn't always useful, but it
might be, depending on your requirements.
W
On Mar 1, 2009, at 5:09 AM, Johan Compagner wrote:
> You shouldnt put that object directly in a CPM, but have a loadabled
> detachable model in between. Because now you probably have that hib
> object in the page between requests
>
> On 28/02/2009, Stephen Swinsburg <s....@lancaster.ac.uk> wrote:
>> Hi all,
>>
>> I'm after your thoughts on the following method.
>>
>> Suppose there is a wicket form with some fields that can map directly
>> to a simple Hibernate object, and hence a db table. Is it safe to
>> simply wrap this object in a CompoundPropertyModel and use it as the
>> backing model for the form?
>> Then in the onSubmit method, calling a method to get the object from
>> the form's model and saving it via Hibernate.
>>
>> This does work fine, I'm just after any pitfalls that might happen
>> down the track. Very simple form here.
>>
>> thanks.
>> S
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: bad practice in sharing models between wicket form and hibernate?
Posted by Johan Compagner <jc...@gmail.com>.
You shouldnt put that object directly in a CPM, but have a loadabled
detachable model in between. Because now you probably have that hib
object in the page between requests
On 28/02/2009, Stephen Swinsburg <s....@lancaster.ac.uk> wrote:
> Hi all,
>
> I'm after your thoughts on the following method.
>
> Suppose there is a wicket form with some fields that can map directly
> to a simple Hibernate object, and hence a db table. Is it safe to
> simply wrap this object in a CompoundPropertyModel and use it as the
> backing model for the form?
> Then in the onSubmit method, calling a method to get the object from
> the form's model and saving it via Hibernate.
>
> This does work fine, I'm just after any pitfalls that might happen
> down the track. Very simple form here.
>
> thanks.
> S
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: bad practice in sharing models between wicket form and hibernate?
Posted by Martijn Reuvers <ma...@gmail.com>.
Hello Stephen,
Does not sound like a problem to me. As long as your hibernate session
is closed after the save you do, this object will be in a detached
state and generally should cause no trouble (same goes for if you
fetch an object from the database thru hibernate).
Martijn
On Sat, Feb 28, 2009 at 7:20 PM, Stephen Swinsburg
<s....@lancaster.ac.uk> wrote:
> Hi all,
>
> I'm after your thoughts on the following method.
>
> Suppose there is a wicket form with some fields that can map directly to a
> simple Hibernate object, and hence a db table. Is it safe to simply wrap
> this object in a CompoundPropertyModel and use it as the backing model for
> the form?
> Then in the onSubmit method, calling a method to get the object from the
> form's model and saving it via Hibernate.
>
> This does work fine, I'm just after any pitfalls that might happen down the
> track. Very simple form here.
>
> thanks.
> S
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: bad practice in sharing models between wicket form and hibernate?
Posted by Brill Pappin <br...@pappin.ca>.
I do it all the time. Its transient anyway unless you actually persist
or merge it (unless your entity beans handle persistence on change
themselves).
Actually, I typically have a form data object, one of the fields being
the entity I'm creating. I usually do that so that custom values can
be handled before I set them on the entity, such as a single date
property I want split up on the form.
- Brill
On 28-Feb-09, at 1:20 PM, Stephen Swinsburg wrote:
> Hi all,
>
> I'm after your thoughts on the following method.
>
> Suppose there is a wicket form with some fields that can map
> directly to a simple Hibernate object, and hence a db table. Is it
> safe to simply wrap this object in a CompoundPropertyModel and use
> it as the backing model for the form?
> Then in the onSubmit method, calling a method to get the object from
> the form's model and saving it via Hibernate.
>
> This does work fine, I'm just after any pitfalls that might happen
> down the track. Very simple form here.
>
> thanks.
> S
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: bad practice in sharing models between wicket form and hibernate?
Posted by Dave Schoorl <ma...@cyber-d.com>.
In my current project I do just that and it works fine. I must add that
it is a highly interactive application, so I work with long
conversations (managed hibernate sessions), where the transaction is
committed only after a number of request/response cycles after the user
clicks on 'save'. During the conversation my business objects are in
persistent state (never detached), and I wrap every business object in a
LDM, except I do not load from database, but from EhCache.
The only thing that I had to do, is move all validation, even simple
syntax checking, like field lengths, required fields etc., out of the
business objects, because I create a domain object with a default
(no-arg) constructor and add it to the Hibernate session. At that
moment, the object has invalid state (required fields have no data etc.)
So I have to trust on form validation and/or guide each object through a
validator before it is saved to the database or actually used in the
domain layer. Maintaining the objects validity combined with the
separation of layers is, I think, the only 'pitfall' I encountered that
I have not yet found a completely satisfactory answer for.
Hope this helps.
Stephen Swinsburg wrote:
> Hi all,
>
> I'm after your thoughts on the following method.
>
> Suppose there is a wicket form with some fields that can map directly
> to a simple Hibernate object, and hence a db table. Is it safe to
> simply wrap this object in a CompoundPropertyModel and use it as the
> backing model for the form?
> Then in the onSubmit method, calling a method to get the object from
> the form's model and saving it via Hibernate.
>
> This does work fine, I'm just after any pitfalls that might happen
> down the track. Very simple form here.
>
> thanks.
> S
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org