Hi, I don't have much experience with component/transparent resolvers but here is how I see it.
On Fri, Jul 15, 2011 at 7:03 AM, Igor Vaynberg <[email protected]> wrote: > 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. Yes. With queuing the transparent resolvers will be no more needed. The children components will be found in the queue. I like the term 'bag' instead of queue, because there is no FIFO involved. But this is just terminology... > > 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. sounds feasible. > > 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()). I haven't looked at the patch for queueing but I thought that dequeue will happen at render time, no ? Because I can do addOrReplace() in onBeforeRender() which again will work with the queue, not with the canonicalized (by dequeue) tree. > 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). Currently getParent() is something like findParent(Component.class), i.e. the very first Component in the higher lever is the parent. I'm not sure how this parent will be resolved from the queue of components in a markup container unless the 'id' is specified. About findChild(String id) - what will be the difference with current get(String id) ? And what about the newly introduced get("..:..:a:b:d") ? I.e. get a different branch from the tree. I guess the answer is in how findParent() will work > * 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 > -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com
