You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Igor Vaynberg <ig...@gmail.com> on 2009/09/18 19:55:51 UTC
Re: Is it a bug that Enclosure is not invoking component resolver to
resolve its children?
you are welcome to provide a patch.
-igor
On Thu, Sep 17, 2009 at 1:57 PM, Chris Colman
<ch...@stepaheadsoftware.com> 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: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
RE: Is it a bug that Enclosure is not invoking component resolver to resolve its children?
Posted by Chris Colman <ch...@stepaheadsoftware.com>.
> > >> 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.
>
> What method should I override in Enclosure to invoke the above
process?
>
> It would have to be a method that gets called prior to Enclosure
calling
> getChildComponent() which it does from onComponentBodyTag... does that
> represent a staging problem?
I've tried many different combinations over a frustrating 3 days now in
an attempt to get enclosure to fire off a 'resolve' on its children like
most other parent components do.
I'm beginning to wonder if what I'm doing is actually possible in
wicket.
Perhaps the retrieval of the dependent child component is happening to
early in the lifecycle i.e. before the resolve has had a chance to
instantiate and populate the children in the parent.
Any ideas on the relative chance of success of this endeavour?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
RE: Is it a bug that Enclosure is not invoking component resolver to resolve its children?
Posted by Chris Colman <ch...@stepaheadsoftware.com>.
> >> 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.
What method should I override in Enclosure to invoke the above process?
It would have to be a method that gets called prior to Enclosure calling
getChildComponent() which it does from onComponentBodyTag... does that
represent a staging problem?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
RE: Is it a bug that Enclosure is not invoking component resolver to resolve its children?
Posted by Chris Colman <ch...@stepaheadsoftware.com>.
> > >> 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, ....)
I've tried invoking the application resolvers from many different places
within the Enclosure class but without any success. It ranges from
obscure NPEs to 'child not found' errors. I'm not quite sure where
exactly the resolvers should be invoked and what the 'container'
parameter should be: I don't think it should be the Enclosure itself as
it's a transparent parent - I tried the enclosure's parent but that
fails. I don't know what else to try.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
RE: Is it a bug that Enclosure is not invoking component resolver to resolve its children?
Posted by Chris Colman <ch...@stepaheadsoftware.com>.
> >> 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, ....)
Yes looks like this code in MarkupContainer.renderNext would need to be
factored out:
// 3rd try: Try application's component resolvers
final List<IComponentResolver> componentResolvers =
getApplication().getPageSettings()
.getComponentResolvers();
final Iterator<IComponentResolver> iterator =
componentResolvers.iterator();
while (iterator.hasNext())
{
final IComponentResolver resolver = iterator.next();
if (resolver.resolve(this, markupStream, tag))
{
return;
}
}
I also had a similar problem with wicket:border - maybe it has the same
problem of not providing an opportunity for the component resolvers to
resolve the markup's 'child' components.
This issue may affect other 'enclosing' type wicket tags as well. Maybe
it really needs someone who knows more about wicket than me to refactor
it properly and provide the necessary hooks so that component resolvers
are invoked in the right places.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
RE: Is it a bug that Enclosure is not invoking component resolver to resolve its children?
Posted by Chris Colman <ch...@stepaheadsoftware.com>.
> to resolve the wicket:enclosure tag itself.
>
> the tag handler will assign a wicket:id to the wicket:enclosure tag.
> the component resolver then has to resolve that wicket:id to a
> component.
Ah, ok. At first it seemed strange to need an EnclosureResolver when
wicket already knew that it was an Enclosure but now that you explain it
as a two phase process:
1) handle tag to get a wicket:id
2) resolve the enclosure component i.e. look for a component with that
wicket:id
it now makes sense.
>
> -igor
>
> On Fri, Sep 18, 2009 at 8:35 PM, Chris Colman
> <ch...@stepaheadsoftware.com> wrote:
> >> to make the component a direct child of enclosure you would have to
> >> have an Enclosure component that is explicitly added into the
> >> hierarchy, at which point you can simply use a WebMarkupContainer
> >> whose visibility is tied to that of the child to replicate the
> >> functionality. the whole point of enclosure is that there is no
> >> java-side component.
> >
> > Ok, well I'll drop that approach as an option.
> >
> > One thing I don't understand:
> >
> > [This question applies to any markup type/resolver pair I suppose]
> >
> > Is EnclosureResolver.resolve meant to be called to resolve the
children
> > of an Enclosure or to resolve the Enclosure itself?
> >
> >
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Is it a bug that Enclosure is not invoking component resolver to
resolve its children?
Posted by Igor Vaynberg <ig...@gmail.com>.
to resolve the wicket:enclosure tag itself.
the tag handler will assign a wicket:id to the wicket:enclosure tag.
the component resolver then has to resolve that wicket:id to a
component.
-igor
On Fri, Sep 18, 2009 at 8:35 PM, Chris Colman
<ch...@stepaheadsoftware.com> wrote:
>> to make the component a direct child of enclosure you would have to
>> have an Enclosure component that is explicitly added into the
>> hierarchy, at which point you can simply use a WebMarkupContainer
>> whose visibility is tied to that of the child to replicate the
>> functionality. the whole point of enclosure is that there is no
>> java-side component.
>
> Ok, well I'll drop that approach as an option.
>
> One thing I don't understand:
>
> [This question applies to any markup type/resolver pair I suppose]
>
> Is EnclosureResolver.resolve meant to be called to resolve the children
> of an Enclosure or to resolve the Enclosure itself?
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
RE: Is it a bug that Enclosure is not invoking component resolver to resolve its children?
Posted by Chris Colman <ch...@stepaheadsoftware.com>.
> to make the component a direct child of enclosure you would have to
> have an Enclosure component that is explicitly added into the
> hierarchy, at which point you can simply use a WebMarkupContainer
> whose visibility is tied to that of the child to replicate the
> functionality. the whole point of enclosure is that there is no
> java-side component.
Ok, well I'll drop that approach as an option.
One thing I don't understand:
[This question applies to any markup type/resolver pair I suppose]
Is EnclosureResolver.resolve meant to be called to resolve the children
of an Enclosure or to resolve the Enclosure itself?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Is it a bug that Enclosure is not invoking component resolver to
resolve its children?
Posted by Igor Vaynberg <ig...@gmail.com>.
to make the component a direct child of enclosure you would have to
have an Enclosure component that is explicitly added into the
hierarchy, at which point you can simply use a WebMarkupContainer
whose visibility is tied to that of the child to replicate the
functionality. the whole point of enclosure is that there is no
java-side component.
-igor
On Fri, Sep 18, 2009 at 4:27 PM, Chris Colman
<ch...@stepaheadsoftware.com> wrote:
>> > 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
>> >> <ch...@stepaheadsoftware.com> 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: users-unsubscribe@wicket.apache.org
>> >> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >> >
>> >> >
>> >> > ---------------------------------------------------------------------
>> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> > For additional commands, e-mail: users-help@wicket.apache.org
>> >> >
>> >> >
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> > For additional commands, e-mail: users-help@wicket.apache.org
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
RE: Is it a bug that Enclosure is not invoking component resolver to resolve its children?
Posted by Chris Colman <ch...@stepaheadsoftware.com>.
> > 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
> >> <ch...@stepaheadsoftware.com> 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: users-unsubscribe@wicket.apache.org
> >> >> For additional commands, e-mail: users-help@wicket.apache.org
> >> >
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> > For additional commands, e-mail: users-help@wicket.apache.org
> >> >
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Is it a bug that Enclosure is not invoking component resolver to
resolve its children?
Posted by Igor Vaynberg <ig...@gmail.com>.
On Fri, Sep 18, 2009 at 3:02 PM, Chris Colman
<ch...@stepaheadsoftware.com> wrote:
>> you are welcome to provide a patch.
>>
>> -igor
>
> I would if I could get it working ;).
>
> 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
> 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
>> <ch...@stepaheadsoftware.com> 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: users-unsubscribe@wicket.apache.org
>> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> > For additional commands, e-mail: users-help@wicket.apache.org
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
RE: Is it a bug that Enclosure is not invoking component resolver to resolve its children?
Posted by Chris Colman <ch...@stepaheadsoftware.com>.
> you are welcome to provide a patch.
>
> -igor
I would if I could get it working ;).
At what point in the lifecycle of normal parent should the component resolver be invoked to instantiate the children?
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?
Regards,
Chris
>
> On Thu, Sep 17, 2009 at 1:57 PM, Chris Colman
> <ch...@stepaheadsoftware.com> 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: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org