On Thu, Jan 23, 2014 at 8:20 AM, Martin Grigorov <mgrigo...@apache.org> wrote: > Once the markup driven construction is done (just before onInitialize()) > the application will have to use the old good add()/addOrReplace().
yeah, but onInitialize() is there to partially replace the constructor as a place to add components. > 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). yes, thats the 8 bytes i was talking about. considering some pages have easily over a hundred components that adds up. > Serialization is the same - the object is written once, with several > pointers. no, serialization will suffer from the same 8 bytes per component reference issue. that means thats a bunch more bytes to shuffle to and from disk and also across network when clustered. > 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 ?! something like this cannot be enabled/disabled. if a component library uses it then it will fail on applications where this is disabled. also, what happens in situations where ids are not unique? then those cannot be put into the hierarchy? its common to have structure like this: <a wicket:id="remove"><span wicket:id="label"></span></a><a wicket:id="add"><span wicket:id="label"></a> another exception is the repeater, unless you create a custom subclass of Item which no one ever does. seems to me there are too many gotchas for all but the most trivial cases. couple this together with the fact that it has to be enabled as mentioned above would put me at -0.5 for this for now. -igor > 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 >>
