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

2009-03-01 Thread Johan Compagner
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

2009-03-01 Thread subbu_tce

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?

2009-03-01 Thread Willis Blackburn
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?

2009-03-01 Thread Johan Compagner
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

2009-03-01 Thread TH Lim

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

2009-03-01 Thread Igor Vaynberg
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?

2009-03-01 Thread Willis Blackburn

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

2009-03-01 Thread Jeremy Thomerson
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

2009-03-01 Thread Timo Rantalaiho
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

2009-03-01 Thread Timo Rantalaiho
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

2009-03-01 Thread Timo Rantalaiho
 [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

2009-03-01 Thread Jan Kriesten

 [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

2009-03-01 Thread Martin Makundi
 [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

2009-03-01 Thread Erik van Oosten

[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

2009-03-01 Thread Johan Edstrom
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