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
Wicket - Multi Instance Support
Hi, Does wicket provide any support for multiple application instances per user's session? In other words, how does wicket handle multiple browser windows for the sample application. Thanks. -- View this message in context: http://www.nabble.com/Wicket---Multi-Instance-Support-tp22271257p22271257.html Sent from the Wicket - User mailing list archive at Nabble.com. - 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: Multiple Forms in A Border
I found out that this exception only happened to Wicket-1.4. I tried Wicket 1.3.5 and it worked fine. I presume all Wicket 1.3.x works too. -- View this message in context: http://www.nabble.com/Multiple-Forms-in-A-Border-tp22252817p22273577.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Multiple Forms in A Border
file a jira bug with a quickstart please. -igor On Sun, Mar 1, 2009 at 6:34 AM, TH Lim ssh...@gmail.com wrote: I found out that this exception only happened to Wicket-1.4. I tried Wicket 1.3.5 and it worked fine. I presume all Wicket 1.3.x works too. -- View this message in context: http://www.nabble.com/Multiple-Forms-in-A-Border-tp22252817p22273577.html Sent from the Wicket - User mailing list archive at Nabble.com. - 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
Re: Wicket - Multi Instance Support
Multiple browser windows viewing the same application? You can turn on multi-window support in your application init method by adding: getPageMapSettings().setAutomaticMultiwindowSupport(true) - I think that's the naming This uses different page maps for each window / tab that's open. -- Jeremy Thomerson http://www.wickettraining.com On Sun, Mar 1, 2009 at 4:51 AM, subbu_tce subramanian.mur...@gmail.comwrote: Hi, Does wicket provide any support for multiple application instances per user's session? In other words, how does wicket handle multiple browser windows for the sample application. Thanks. -- View this message in context: http://www.nabble.com/Wicket---Multi-Instance-Support-tp22271257p22271257.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: LDM with Generics for DropDownChoice
On Wed, 25 Feb 2009, Timo Rantalaiho wrote: I'd say that ListView is wrong here. I created a new Jira issue on fixing that https://issues.apache.org/jira/browse/WICKET-2126 and will do if there are no objections or better ideas. Well, Igor objected very convincingly :) So now there remains the chance of narrowing the DropDownChoice choices list model back to the wildcardless form. Or do you have other ideas of how to resolve this? Best wishes, Timo - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
[vote] In Wicket 1.4 and onwards, remove widening from the list of choices model in DropDownChoice, changing it from IModelList? extends Foo to IModelListFoo
Background: https://issues.apache.org/jira/browse/WICKET-1512 https://issues.apache.org/jira/browse/WICKET-2126 http://www.nabble.com/LDM-with-Generics-for-DropDownChoice-td22155211.html This works: = clips public static void main(String[] args) { Foo foo = new Foo(); foo.bar().add(new String(quux)); } @SuppressWarnings(unchecked) public ListString bar() { List? extends String list = new ArrayListString(Arrays.asList(foo, bar)); return (ListString) list; } = /clips === This doesn't work: = claps public static void main(String[] args) { Foo foo = new Foo(); foo.bar().add(new String(quux)); } public List? extends String bar() { List? extends String list = new ArrayListString(Arrays.asList(foo, bar)); return list; } = /claps === [ ] Yes, change the DropDownChoice constructor to take the choices list as IModelListT or ListT without the wildcard [ ] No, keep DropDownChoice as it is in Wicket 1.4-rc2 Best wishes, Timo -- Timo Rantalaiho Reaktor Innovations OyURL: http://www.ri.fi/ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [vote] In Wicket 1.4 and onwards, remove widening from the list of choices model in DropDownChoice, changing it from IModelList? extends Foo to IModelListFoo
[X] Yes, change the DropDownChoice constructor to take the choices list as IModelListT or ListT without the wildcard - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [vote] In Wicket 1.4 and onwards, remove widening from the list of choices model in DropDownChoice, changing it from IModelList? extends Foo to IModelListFoo
[X] Yes, change the DropDownChoice constructor to take the choices list as IModelListT or ListT without the wildcard [ ] No, keep DropDownChoice as it is in Wicket 1.4-rc2 Best regards, --- Jan. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [vote] In Wicket 1.4 and onwards, remove widening from the list of choices model in DropDownChoice, changing it from IModelList? extends Foo to IModelListFoo
[X] Yes, change the DropDownChoice constructor to take the choices list as IModelListT or ListT without the wildcard ** Martin - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [vote] In Wicket 1.4 and onwards, remove widening from the list of choices model in DropDownChoice, changing it from IModelList? extends Foo to IModelListFoo
[X] Yes, change the DropDownChoice constructor to take the choices list as IModelListT or ListT without the wildcard Regards, Erik. -- Erik van Oosten http://day-to-day-stuff.blogspot.com/ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: GSoC ideas for 09
Having done Gsoc for 2008 (Unrelated OSS project) I'd suggest extremely well defined projects, extremely clear project management and quite a few introductions for tasks expected, not to mention multiple mentors (For picking up slack) defined targets and monitoring as if this was a VC set of money you sat on and expected output from. /je On Feb 25, 2009, at 1:26 AM, C. Bergström wrote: Hi Everyone! A year ago I bugged dashorst about why Wicket didn't participate in the 08 GSoC.. This year I've been brainstorming on ideas and want to see what others think could be useful projects for Wicket. Thanks ./Christopher Johan Edstrom j...@opennms.org They that can give up essential liberty to purchase a little temporary safety, deserve neither liberty nor safety. Benjamin Franklin, Historical Review of Pennsylvania, 1759