I've added alternative ways to use MarkupDrivenComponentTreeBuilder: - with org.apache.wicket.MarkupDrivenTreeInitializionListener - with org.apache.wicket.MarkupDrivenComponentTreeBehavior#onConfigure
Both of them do not check the configuration setting whether markup driven tree construction is enabled for now. The approach with MarkupDrivenTreeInitializionListener works the same way as the "inlined" version. The component tree rebuild is activated *after* all Component#onInitialize(). The approach with MarkupDrivenComponentTreeBehavior uses #onConfigure(). Here I had to change Enclosure class - the child component resolving should be done as late as possible just before the rendering phase starts. Martin Grigorov Wicket Training and Consulting On Fri, Jan 24, 2014 at 11:47 AM, Martin Grigorov <mgrigo...@apache.org>wrote: > OK, the new impl is committed. > Now MarkupContainer has #enqueue(Component...) method that adds components > into a list. > Later org.apache.wicket.ComponentTreeBuilder#rebuild() uses the list, and > finally the list is null-yfied in #onDetach() so it is not serialized and > not available for the next requests. I guess the null-yfing can be done > earlier so even the first request have the extra bytes after the rebuild of > the tree. > > No need of @Auto anymore. > > Martin Grigorov > Wicket Training and Consulting > > > On Fri, Jan 24, 2014 at 10:39 AM, Martin Grigorov <mgrigo...@apache.org>wrote: > >> >> >> On Fri, Jan 24, 2014 at 9:48 AM, Sven Meier <s...@meiers.net> wrote: >> >>> > per-component basis - yes, as I explained earlier this is possible >>> with the current impl >>> >>> I must have missed that. Is there an example in the branch? >>> >> >> See >> https://github.com/apache/wicket/blob/markup-driven-component-tree/wicket-core/src/main/java/org/apache/wicket/MarkupContainer.java?source=c#L1886 >> There is no test yet. >> >> >>> >>> I don't understand why there's need for an @Auto annotation. Why would >>> some components be annotated and some not? >> >> >> The annotation was needed to be able to find the component faster. >> I.e. check only annotated fields. If @Auto(id=...) then use the id to >> match against the component tag id. >> >> But with my new idea, the one that will solve the issue with the extra >> bytes, this won't be needed anymore. >> Stay tuned. >> >> >>> >>> >>> behaviors don't have hooks for onInitialize() >>>> >>> >>> It could be done in #onConfigue(), that's early enough. >> >> >> The problem is that it is called for each request. >> For now I think there is no need to rebuild the component tree for each >> request, so we will have to use a guard (e.g. boolean field in the >> component). >> I will consider it. >> >> >>> >>> >>> Additionally I think using Behavior will add a bit more bytes to each >>>> component than the current solution >>>> >>> >>> I don't think that is a problem: IMHO it's important to make this >>> feature optional, so when users don't use it then they do not pay a price. >>> >>> Regards >>> Sven >>> >>> >>> >>> >>> On 01/24/2014 06:35 AM, Martin Grigorov wrote: >>> >>>> On Fri, Jan 24, 2014 at 12:04 AM, Sven Meier <s...@meiers.net> wrote: >>>> >>>> Hi, >>>>> >>>>> I don't think we're heading the right direction with this and I >>>>> wouldn't >>>>> advertise it as anything yet. >>>>> >>>>> I'd like to advertise it anyhow now just to have more people feeding >>>> me >>>> with stoppers, as you and Igor do. Thanks! :-) >>>> >>>> >>>> There are more questions to come but here is one upfront: >>>>> >>>>> >>>>> And it is configurable, by default disabled. >>>>>> >>>>> As Igor has written, this does not work with component libraries which >>>>> depend on the new feature. >>>>> Couldn't this feature be enabled/disabled on a per-component basis? Why >>>>> not make it a behavior that you can attach to components if you want >>>>> to use >>>>> automatic resolving/rearranging of its children? >>>>> >>>>> - per-component basis - yes, as I explained earlier this is possible >>>> with >>>> the current impl >>>> - behaviors don't have hooks for onInitialize() >>>> After Igor's feedback I think onAfterInitialize() is what is needed, so >>>> apps can use onInitialize() as a complement to the constructor >>>> Additionally I think using Behavior will add a bit more bytes to each >>>> component than the current solution >>>> >>>> >>>> Regards >>>>> Sven >>>>> >>>>> >>>>> >>>>> On 01/23/2014 05:20 PM, Martin Grigorov wrote: >>>>> >>>>> 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 >>>>>>>> >>>>>>>> >>> >> >
