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
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
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
chr...@stepaheadsoftware.com wrote:
to make the
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
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
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
you are welcome to provide a patch.
-igor
On Thu, Sep 17, 2009 at 1:57 PM, Chris Colman
chr...@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
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
On Fri, Sep 18, 2009 at 3:02 PM, Chris Colman
chr...@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
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
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
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
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
13 matches
Mail list logo
