Re: bad practice in sharing models between wicket form and hibernate?
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-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: bad practice in sharing models between wicket form and hibernate?
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.swinsb...@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-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: bad practice in sharing models between wicket form and hibernate?
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.swinsb...@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-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: bad practice in sharing models between wicket form and hibernate?
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 wbo...@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.swinsb...@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-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: bad practice in sharing models between wicket form and hibernate?
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 wbo...@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.swinsb...@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-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
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-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: bad practice in sharing models between wicket form and hibernate?
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.swinsb...@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-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
