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