I am suspending my work on this because I think there is not enough interest in this feature at the moment.
Martin Grigorov Wicket Training and Consulting On Mon, Jan 27, 2014 at 10:07 AM, Martin Grigorov <mgrigo...@apache.org>wrote: > Reading the archives for Igor's work on "component queueing" I see > > Igor > Vaynberg<https://issues.apache.org/jira/secure/ViewProfile.jspa?name=ivaynberg> > added > a comment - 09/Jul/11 23:39 > > @Juergen, right now your tests only test for rendering, but they should > also test that before queued component's oninitialize is called the > component is already a child of the correct parent. > > https://issues.apache.org/jira/browse/WICKET-3335 > > > This means that > org.apache.wicket.application.IComponentInitializationListener cannot be > used. The tree (re)building should happen *before *components' > #onInitialize() and .IComponentInitializationListener#onInitialize() is > called *after*. > > Martin Grigorov > Wicket Training and Consulting > > > On Fri, Jan 24, 2014 at 2:22 PM, Martin Grigorov <mgrigo...@apache.org>wrote: > >> 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 >>>>>>>>>> >>>>>>>>>> >>>>> >>>> >>> >> >
