On 03/07/2013 14:07, Martijn Dashorst wrote:
On Wed, Jul 3, 2013 at 11:35 AM, Jesse Long <[email protected]> wrote:
First, requiring the component to know, at constructor time, the wicket:id
of the tag it will be added to makes creating components difficult and
clumsy.
What is clumsy about it? What is difficult to creating components currently?
I have a base page. It has a div that usually contains some certain
information. Sometimes, in response to form submits etc, this div will
be replaced by something else. I cant do:
this.replaceMySpecialDiv(new MyPanel("Oh damn, what was the component id
here again?"));
Also, I practice "Only the abc.java may be required to know the
component ids in abc.html". Having subclasses of the base page need to
know the component id is untidy.
it would be better:
this.replaceMySpecialDiv(new MyPanel());
protected void replaceMySpecialDiv(Component c)
{
replace("component id ... I am in BasePage.java, so I am allowed to
know component ids in BasePage.html", c);
}
You end up with "public static final String SOMETHING_COMPONENT_ID"
which gets passed into component constructors. The next evolution is to
create a needless subclass that does little other than always pass the
same component id to the super class, like:
public class MySpecialDivPanel
extends Panel
{
public MySpecialDivPanel(IModel.....)
{
super("hardcoded component id", model);
}
}
Look at wicket-bootstrap.
https://github.com/l0rdn1kk0n/wicket-bootstrap/blob/master/bootstrap-core/src/main/java/de/agilecoders/wicket/core/markup/html/bootstrap/navbar/NavbarButton.java
super(Navbar.componentId(), ......
Its clumsy.
What do you think about changing this pattern:
add(new MyComponent("theIdInMarkup"));
to this:
add("theIdInMarkup", new MyComponent());
This allows us to separate the construction of the components from the
populating of the markup.
What is the benefit of this? What are the upsides?
Upside is "less clumsy".
I can think of one downside,
Component#replaceWith() will need some re-working.
I can think of one other: a minor breakage in a little used part of our API.
:-) very important point. However, I'm not pushing this for 6.9.1. I'm
happy to wait for 6.9.2 :-)
No harm in discussing it though. I think its about as disruptive as the
changes proposed in Wicket 2. It need not be black and white, we may be
able to accommodate both approaches. Either way, if the only down side
is API breakage, and generally accepted as a good thing, then maybe we
can implement it one day when something else causes API breakage.
Cheers,
Jesse
