At https://git-wip-us.apache.org/repos/asf/wicket/repo?p=wicket.git;a=commitdiff;h=6ba324dba2eab841cedc5426f4560946f8688b10you may see a very simple demo of the idea.
A new test is added - a base page with three component which are *not *added to the page and three specializations of that page without Java code but different markup (different component tree). Martin Grigorov Wicket Training and Consulting On Wed, Jan 22, 2014 at 10:12 PM, Martin Grigorov <mgrigo...@apache.org>wrote: > 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 >
