working with this wicket:for stuff makes me really hate all the
autoresolver and autocomponent stuff. if only add() did what queue()
from the component queueing discussions does we would be able to get
rid of auto components and make them full fledged components instead.
look at this:
<div wicket:id="container">
<wicket:enclosure child="name">
<label wicket:for="name">
<wicket:label>name</wicket:label>:
</label>
<input wicket:id="prefix" type="text"/>
<input wicket:id="name" type="text"/>
<input wicket:id="suffix" type="text"/>
</wicket:enclosure>
</div>
given this examples the java hierarchy looks like this
container { prefix, name, suffix }
markup hierarchy looks like this
container { enclosure { label { labeltext }, prefix, name, suffix } }
and render hierarchy with a lot of magic from component resolvers and
autocomponents looks like this
container { enclosure, label, labeltext, prefix, name, suffix }
thats three representations for the same component tree.
because java and markup hierarchy dont match we have a lot of stupid
problems like auto components that cannot maintain state - cannot use
a resolver to add a form component and prefix and suffix component's
visibility/form processing is messed up because they are invisible
during render time due to enclosure, but visible during form submit
processing time.
we also have a lot of ugly hacks like transparent resolvers.
now, what if add() did what queue() does...
autoresolvers, if run before component deqeueing, can perform an
actual java hierarchy add of their resolved components such as
enclosures. then dequeue runs and it adds user components into the
correct parent containers. in this case the java hierarchy would look
like the markup hierarchy and everything would Just Work (tm) without
any problems.
how things would be different from the world of 1.x?
well, a component's hierarchy is nondeterministic before its
oninitialize() method is called (dequeueing happens before
oninitialize()). this means that potentially if getParent() is called
before and after onInitialize() it may return different results.
However, the way that queuing works is that if A.add(B) then A is
guaranteed to be an ancestor of B. which means if we remove
getParent() and start relying on findParent(Class) we should be OK (of
course unless an auto resolver adds such a class in the middle, but
that should be rather rare).
so the proposal for 2.0 is this:
* replace our parent.add(child) model with parent.queue(child) model
(keeping the method named 'add'). remove all absolute hierarchy
traversal methods such as getParent() and get() and, where
appropriate, replace with a relative traversal such as
findParent(class) and findChild(String id).
* rewire component resolvers to run before dequeueing and use normal
add() instead of autoadd() - they will also have to set wicket:ids in
the markup so their components can be dequeued as well.
i dont know if this will hold water, its just an idea that sprung out
of frustration. thoughts?
-igor
