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
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
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?
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
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
using addSomeEventHandler would also remove the need for:
@Override
protected boolean
wantOnSelectionChangedNotifications() {
return true;
}
in DropDownChoice
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
