I gave the idea to resolve components after onInitalize() a try by re-using ComponentResolvers to resolve the auto-components. They are added (not queued) at the right place in the hierarchy. Component's queued will be added to the auto-components as well, so that the hierarchies (markup and components) are in sync. Auto-components are no longer removed and can have state.
The approach doesn't require any other fundamental changes like findParent() etc. I removed auto-add and resolve during render phase to find potential issues. Only 1 test case is still failing, even though it's a proof of concept only. I push it to git tonight in case you are interested. -Juergen On Fri, Jul 15, 2011 at 1:42 PM, Martin Grigorov <[email protected]> wrote: > 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 >
