Just uploaded it to https://github.com/jdonnerstag/wicket/tree/autoadd
Juergen On Thu, Jul 21, 2011 at 9:48 AM, Juergen Donnerstag <[email protected]> wrote: > 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 >> >
