https://github.com/jdonnerstag/wicket/commit/e5150ecb58fb9617120911b3b984767009f9f9d6
-Juergen On Fri, Jul 22, 2011 at 9:09 AM, Martin Grigorov <[email protected]> wrote: > 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 >
