Hi,
Recently Fridolin Jackstadt shared his approach to "autowire" components -
https://github.com/wicket-acc/wicket-autowire.
I believe this approach can solve two issues:
- duplicate construction of the component tree - once in the markup and
second time in Java code
- auto components available only in the render phase
Here is how I see it:
Any MarkupContainer that wants to use markup-driven-tree must declare the
components as member fields:
private SomeComponent aComponent;
These fields will be instantiated like any other component in Wicket:
aComponent = new SomeComponent(id, ...);
The new thing is that they *won't* be added to a parent component
explicitly/manually.
On Page#onInitialize() the first thing to do it to walk over the component
tree from the page's markup (just like the walk in the rendering related
code) and resolve the missing bits.
I.e. while walking thru the markup tree we will check the Java component
tree (container.get(tagId)). If there is a miss then we search for a member
field that is a component with the same id in the current MarkupContainer,
its (Java) super classes and finally in its (Wicket) parent classes.
This will solve issue #1 (identical trees in Java and markup)
(P.S. Fridolin's code uses @AutoComponent annotation that facilitates
searching by component id, but will duplicate the declaration of the id -
once in the annotation and second time in 'new MyComponent(ID). This is an
implementation detail.)
The second part is not less hard - during the walk over the markup tree
when an autocomponent (e.g. enclosure) is seen Wicket will use the
registered IComponentResolvers to create the Java component and insert it
in the Java tree.
The tricky part here is that any manually added components (like in Wicket
6.x) to the parent of the autocomponent should be moved into the
autocomponent.
For example:
<div wicket:id="a">
<wicket:enclosure child="b">
<span wicket:id="b"></span>
<span wicket:id="c"></span>
</wicket:enclosure>
</div>
If 'b' and 'c' are added manually to 'a' in the application's Java code:
(a (b,c))
then after the "resolving phase" the tree will be:
a (enclosure(b, c))
so b.getParent() in onInitialize() and later will return the Enclosure, not
'a'.
I don't know very well the MarkupStream APIs but I think all this should be
possible.
WDYT about this approach ?
Martin Grigorov
Wicket Training and Consulting
