Re: bad practice in sharing models between wicket form and hibernate?

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

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

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

[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