> > At what point in the lifecycle of normal parent should the component > resolver be invoked to instantiate the children? > > this happens during render time when wicket is trying to match up > markup to a component
I'm wondering if Enclosure, with its need to obtain knowledge of its 'child' (which is really it's sibling!) is prematurely trying to reach its child (sibling) before the normal 'child component resolution' process has processed the child. Perhaps this wouldn't be a problem if the 'child' of an enclosure actually *was* a true child of the enclosure rather than being its sibling.... hmmmm. That might allow the Enclosure's own 'child resolution process' to work via the normal parent/child component resolution mechanism. In that case it might just work if the following line: final Component< ? > child = parent.get(childId.toString()); was changed to final Component< ? > child = get(childId.toString()); How do you feel about that approach? Regards, Chris > > > And... is there a convention for calling the component resolvers? > There's obviously a collection of them in the settings so does this need > to be iterated through until one returns 'true' or is there somewhere in > the framework where this iterating code can be called? > > as far as i rememember there is a collection registered in setttings > and then each component can also implement a resolver. > > the contract can be seen in markupcontainer#rendernext method > 1) first walk over the component hierarchy and check if any are resolvers > 2) walk over collection of resolvers in the settings > > as soon as true is returned from resolve iteration is stopped. > > this contract is not factored out anywhere, but maybe doing so may be > worthwhile. can be part of your patch, something like > ComponentResolvers.resolve(MarkupContainer parent, ....) > > hope this gets you started. > -igor > > > > > > > Regards, > > Chris > > > >> > >> On Thu, Sep 17, 2009 at 1:57 PM, Chris Colman > >> <[email protected]> wrote: > >> > As can be seen by the Enclosure.getChildComponent method below the > >> > component resolver expects to find the 'child' within its own parent > - > >> > i.e. it assumes that its *child* is actually its sibling via: > >> > > >> > child = parent.get(childId.toString()); > >> > > >> > While all other children of the common parent are resolved perfectly > by > >> > the component resolver the fact that the enclosure's child is not > really > >> > a child of the enclosure's parent (at least not in the markup) but > >> > rather a child of the enclosure itself seems to mean that the normal > >> > resolving mechanism that allowed all other 'siblings' to be > instantiated > >> > by my custom component resolver is bypassed. > >> > > >> > Is that a bug? If it is a bug is there something I can do to work > around > >> > this to make this 'child' get resolved like all the other children of > >> > the enclosure's parent? i.e. somehow cause my custom component > resolver > >> > to be invoke like it is for the other children. > >> > > >> > > >> >> public Component< ? > getChildComponent() > >> >> { > >> >> if (childComponent == null) > >> >> { > >> >> MarkupContainer< ? > parent = > >> >> getEnclosureParent(); > >> >> > >> >> if (childId == null) > >> >> { > >> >> throw new MarkupException( > >> >> "You most likely forgot to > >> >> register the EnclosureHandler with the MarkupParserFactory"); > >> >> } > >> >> > >> >> final Component< ? > child = > >> >> parent.get(childId.toString()); > >> >> if (child == null) > >> >> { > >> >> throw new MarkupException( > >> >> "Didn't find child component > of > >> >> <wicket:enclosure> with id='" + childId + > >> >> "'. Component: " + > >> >> this.toString()); > >> >> } > >> >> childComponent = child; > >> >> } > >> >> return childComponent; > >> >> } > >> >> > >> >> -------------------------------------------------------------------- > - > >> >> To unsubscribe, e-mail: [email protected] > >> >> For additional commands, e-mail: [email protected] > >> > > >> > > >> > --------------------------------------------------------------------- > >> > To unsubscribe, e-mail: [email protected] > >> > For additional commands, e-mail: [email protected] > >> > > >> > > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [email protected] > >> For additional commands, e-mail: [email protected] > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
