I don't see any commit message related to autoadd at https://github.com/jdonnerstag/wicket/commits/autoadd Can you give url to the commit(s) so we can see the diffs ?
On Thu, Jul 21, 2011 at 11:29 PM, Juergen Donnerstag <[email protected]> wrote: > 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 >>> >> > -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com
