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 >>>>>>> >>>>>>> >> >
