You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Sam Hough <sa...@redspr.com> on 2007/08/31 10:54:04 UTC
MarkupContainer.get(path) or hold reference?
Any distinct differences between using MarkupContainer.get(path) or just
holding a reference to a component? The latter seems faster and more
consistent with GWT/Swing?
Got a vague memory of reading somewhere that holding lots of references to
Components is an anti-pattern but I can't find it again and I don't think it
elaborated.
I'm thinking of simple use cases like wanting to disable a button during an
event. So should I do get("myButton") or when I create the button hold onto
a reference?
Thanks
Sam
--
View this message in context: http://www.nabble.com/MarkupContainer.get%28path%29-or-hold-reference--tf4358991.html#a12422870
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: MarkupContainer.get(path) or hold reference?
Posted by Eelco Hillenius <ee...@gmail.com>.
On 8/31/07, Igor Vaynberg <ig...@gmail.com> wrote:
> we went with the cheapest variant possible as default. a callback method
> doesnt have the memory overhead of holding onto a list, besides since
> buttons/links 99% of the time only have a single listener anyways it makes
> sense.
>
> if you have a lot of cases where you need more then one listener you can
> create a subclass that delegates the call.
Also, we've discussed this with Jonathan in a very early stage in the
project, and he said he just thought it was simpler/ easier. And we
agree.
Eelco
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: MarkupContainer.get(path) or hold reference?
Posted by Igor Vaynberg <ig...@gmail.com>.
we went with the cheapest variant possible as default. a callback method
doesnt have the memory overhead of holding onto a list, besides since
buttons/links 99% of the time only have a single listener anyways it makes
sense.
if you have a lot of cases where you need more then one listener you can
create a subclass that delegates the call.
-igor
On 8/31/07, Sam Hough <sa...@redspr.com> wrote:
>
>
> Thanks Eelco,
>
> On a related subject. Why does Wicket get us to do:
> new Button("id") {
> @Override
> public void onSubmit() {
> }
> };
>
> rather than:
> Button b = new Button("id");
> b.addOnSubmit(new SubmitHandler() {
> public void onSubmit(Field f) {
> }
> }};
> ? The latter seems more common elsewhere. Is it taste or something more
> concrete?
>
> I was sulking a bit trying to do:
> final Button a = new Button("a");
> final Button b = new Button("b");
> a. addOnSubmit(new SubmitHandler() {
> public void onSubmit(FIeld f) {
> a.setEnabled(false);
> b.setEnabled(true);
> }
> };
> b.addOnSubmit(new SubmitHandler() {
> public void onSubmit(Field f) {
> a.setEnabled(true);
> b.setEnabled(false);
> }
> };
> Probably me still trying to convert from GWT ;)
>
>
>
>
>
> Eelco Hillenius wrote:
> >
> >> Great. I must have just imagined the anti-pattern comment or got it the
> >> wrong
> >> way around.
> >
> > An anti pattern in Wicket 1.2 would be to keep passing pages in to
> > other pages. One back page is no problem, but a linked list out of
> > them would eat considerable memory. In Wicket 1.3 this is hardly
> > relevant since Johan and Matej optimized the hell out of how pages are
> > serialized.
> >
> > And just in general, keep in mind that everything that can be
> > referenced from components/ a page means it is part of it's state
> > (which might hurt you in a cluster if you over-do it).
> >
> > Eelco
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/MarkupContainer.get%28path%29-or-hold-reference--tf4358991.html#a12424669
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: MarkupContainer.get(path) or hold reference?
Posted by Sam Hough <sa...@redspr.com>.
using addSomeEventHandler would also remove the need for:
@Override
protected boolean wantOnSelectionChangedNotifications() {
return true;
}
in DropDownChoice presumably?
--
View this message in context: http://www.nabble.com/MarkupContainer.get%28path%29-or-hold-reference--tf4358991.html#a12424932
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: MarkupContainer.get(path) or hold reference?
Posted by Sam Hough <sa...@redspr.com>.
Thanks Eelco,
On a related subject. Why does Wicket get us to do:
new Button("id") {
@Override
public void onSubmit() {
}
};
rather than:
Button b = new Button("id");
b.addOnSubmit(new SubmitHandler() {
public void onSubmit(Field f) {
}
}};
? The latter seems more common elsewhere. Is it taste or something more
concrete?
I was sulking a bit trying to do:
final Button a = new Button("a");
final Button b = new Button("b");
a. addOnSubmit(new SubmitHandler() {
public void onSubmit(FIeld f) {
a.setEnabled(false);
b.setEnabled(true);
}
};
b.addOnSubmit(new SubmitHandler() {
public void onSubmit(Field f) {
a.setEnabled(true);
b.setEnabled(false);
}
};
Probably me still trying to convert from GWT ;)
Eelco Hillenius wrote:
>
>> Great. I must have just imagined the anti-pattern comment or got it the
>> wrong
>> way around.
>
> An anti pattern in Wicket 1.2 would be to keep passing pages in to
> other pages. One back page is no problem, but a linked list out of
> them would eat considerable memory. In Wicket 1.3 this is hardly
> relevant since Johan and Matej optimized the hell out of how pages are
> serialized.
>
> And just in general, keep in mind that everything that can be
> referenced from components/ a page means it is part of it's state
> (which might hurt you in a cluster if you over-do it).
>
> Eelco
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/MarkupContainer.get%28path%29-or-hold-reference--tf4358991.html#a12424669
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: MarkupContainer.get(path) or hold reference?
Posted by Eelco Hillenius <ee...@gmail.com>.
> Great. I must have just imagined the anti-pattern comment or got it the wrong
> way around.
An anti pattern in Wicket 1.2 would be to keep passing pages in to
other pages. One back page is no problem, but a linked list out of
them would eat considerable memory. In Wicket 1.3 this is hardly
relevant since Johan and Matej optimized the hell out of how pages are
serialized.
And just in general, keep in mind that everything that can be
referenced from components/ a page means it is part of it's state
(which might hurt you in a cluster if you over-do it).
Eelco
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: MarkupContainer.get(path) or hold reference?
Posted by Sam Hough <sa...@redspr.com>.
Great. I must have just imagined the anti-pattern comment or got it the wrong
way around.
Thanks
Eelco Hillenius wrote:
>
>> Any distinct differences between using MarkupContainer.get(path) or just
>> holding a reference to a component? The latter seems faster and more
>> consistent with GWT/Swing?
>>
>> Got a vague memory of reading somewhere that holding lots of references
>> to
>> Components is an anti-pattern but I can't find it again and I don't think
>> it
>> elaborated.
>>
>> I'm thinking of simple use cases like wanting to disable a button during
>> an
>> event. So should I do get("myButton") or when I create the button hold
>> onto
>> a reference?
>
> I would hold onto a reference. Much better when you refactor and for
> tracking down what happens in your code. And it doesn't matter for
> memory consumption here, as you'd have myButton in your hierarchy
> anyway, right?
>
> Eelco
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/MarkupContainer.get%28path%29-or-hold-reference--tf4358991.html#a12423048
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: MarkupContainer.get(path) or hold reference?
Posted by Eelco Hillenius <ee...@gmail.com>.
> Any distinct differences between using MarkupContainer.get(path) or just
> holding a reference to a component? The latter seems faster and more
> consistent with GWT/Swing?
>
> Got a vague memory of reading somewhere that holding lots of references to
> Components is an anti-pattern but I can't find it again and I don't think it
> elaborated.
>
> I'm thinking of simple use cases like wanting to disable a button during an
> event. So should I do get("myButton") or when I create the button hold onto
> a reference?
I would hold onto a reference. Much better when you refactor and for
tracking down what happens in your code. And it doesn't matter for
memory consumption here, as you'd have myButton in your hierarchy
anyway, right?
Eelco
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org