Hi,
I don't think we're heading the right direction with this and I wouldn't
advertise it as anything yet.
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?
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
