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