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

Reply via email to