Once the markup driven construction is done (just before onInitialize()) the application will have to use the old good add()/addOrReplace().
The components are already in the MarkupContainer#children data structure. So each field will add extra 8 bytes on 64bit machine (or 4 bytes with CompressedOops enabled). Serialization is the same - the object is written once, with several pointers. I am also not fully sure in the approach but I am experimenting and so far it works well. And it is configurable, by default disabled. We can advertise it as experimental ?! I will add more use cases/tests soon. And caching for the reflection stuff. On Thu, Jan 23, 2014 at 6:09 PM, Igor Vaynberg <igor.vaynb...@gmail.com>wrote: > what about components added in onInitialize() or on onConfigure()? > > this will also lead to a higher memory/serialization space usage since > by default you need a field to store the component ref. > > not sure its worth doing it this way... > > -igor > > > On Wed, Jan 22, 2014 at 12: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 >
