You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Matthijs Wensveen <m....@func.nl> on 2007/12/05 16:15:00 UTC
IComponentResolver question
Hello,
I have developed a panel named AutoComponentPanel that automatically adds wicket components based on (dynamic) markup. Looking at IComponentResolver I noticed some similarities. Can someone explain this class and its uses to me? Is it
something that I should want to use for AutoComponentPanel?
We use AutoComponentPanel as a base class for some other panels that
provide dynamic markup. For example transformed xml (xml -> xslt -> xhtml + wicket:id attributes).
Would it be better (aka the wicket-way (tm))
when AutoComponentPanel is re-written as an IComponentResolver that can
be used by the currently subclassing panels? They would then need to
implement IComponentResolver too but can call my rewritten
AutoComponentPanelAsResolverSomething in their implementing methods.
Would this be a better way to go?
How should this work when I add my resolver with
Application.getPageSettings().addComponentResolver(resolver)?
Thanks,
Matthijs Wensveen
--
Matthijs Wensveen
Func. Internet Integration
W http://www.func.nl
T +31 20 4230000
F +31 20 4223500
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: IComponentResolver question
Posted by Matthijs Wensveen <m....@func.nl>.
Igor Vaynberg wrote:
> icomponentresolver does exactly what its javadoc says - match markup
> tags to components. if you want you can create those components on the
> fly - but remember that this happens at render time so it might have
> some side effects for you.
>
The javadoc mentions "component names", but you can create components
based on anything of the ComponentTag. Would "IComponentResolvers are
responsible for mapping ComponentTags to Wicket components." be a better
description?
Of course, you don't even have to look at the component tag to create a
component (i.e. RandomComponentResolver) but that would be pretty useless :)
> you dont need to rewrite your panel as a component resolver and add it
> to application settings - not many global component resolvers make
> sense unless you use namespaced markup tags.
>
> instead it is most times easier to simply let your component implement
> the interface directly - it works that way too.
>
Okay, that's good to know. I'll do that.
Do I need to add the created component to the container with
container.autoAdd() ?
> if you want to see how it is meant to be used then simply search our
> codebase for references to it.
>
I did do that, but I was unsure whether or not to use it myself.
Thanks for the explanation,
Matthijs
> -igor
>
> On Dec 5, 2007 7:15 AM, Matthijs Wensveen <m....@func.nl> wrote:
>
>> Hello,
>>
>> I have developed a panel named AutoComponentPanel that automatically adds wicket components based on (dynamic) markup. Looking at IComponentResolver I noticed some similarities. Can someone explain this class and its uses to me? Is it
>> something that I should want to use for AutoComponentPanel?
>>
>> We use AutoComponentPanel as a base class for some other panels that
>> provide dynamic markup. For example transformed xml (xml -> xslt -> xhtml + wicket:id attributes).
>> Would it be better (aka the wicket-way (tm))
>> when AutoComponentPanel is re-written as an IComponentResolver that can
>> be used by the currently subclassing panels? They would then need to
>> implement IComponentResolver too but can call my rewritten
>> AutoComponentPanelAsResolverSomething in their implementing methods.
>>
>> Would this be a better way to go?
>>
>> How should this work when I add my resolver with
>> Application.getPageSettings().addComponentResolver(resolver)?
>>
>> Thanks,
>> Matthijs Wensveen
>>
>> --
>> Matthijs Wensveen
>> Func. Internet Integration
>> W http://www.func.nl
>> T +31 20 4230000
>> F +31 20 4223500
>>
>> ---------------------------------------------------------------------
>> 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
>
>
--
Matthijs Wensveen
Func. Internet Integration
W http://www.func.nl
T +31 20 4230000
F +31 20 4223500
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: IComponentResolver question
Posted by Igor Vaynberg <ig...@gmail.com>.
icomponentresolver does exactly what its javadoc says - match markup
tags to components. if you want you can create those components on the
fly - but remember that this happens at render time so it might have
some side effects for you.
you dont need to rewrite your panel as a component resolver and add it
to application settings - not many global component resolvers make
sense unless you use namespaced markup tags.
instead it is most times easier to simply let your component implement
the interface directly - it works that way too.
if you want to see how it is meant to be used then simply search our
codebase for references to it.
-igor
On Dec 5, 2007 7:15 AM, Matthijs Wensveen <m....@func.nl> wrote:
> Hello,
>
> I have developed a panel named AutoComponentPanel that automatically adds wicket components based on (dynamic) markup. Looking at IComponentResolver I noticed some similarities. Can someone explain this class and its uses to me? Is it
> something that I should want to use for AutoComponentPanel?
>
> We use AutoComponentPanel as a base class for some other panels that
> provide dynamic markup. For example transformed xml (xml -> xslt -> xhtml + wicket:id attributes).
> Would it be better (aka the wicket-way (tm))
> when AutoComponentPanel is re-written as an IComponentResolver that can
> be used by the currently subclassing panels? They would then need to
> implement IComponentResolver too but can call my rewritten
> AutoComponentPanelAsResolverSomething in their implementing methods.
>
> Would this be a better way to go?
>
> How should this work when I add my resolver with
> Application.getPageSettings().addComponentResolver(resolver)?
>
> Thanks,
> Matthijs Wensveen
>
> --
> Matthijs Wensveen
> Func. Internet Integration
> W http://www.func.nl
> T +31 20 4230000
> F +31 20 4223500
>
> ---------------------------------------------------------------------
> 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