yes you are right, the interceptor exists only for components which
are not easily found. Suggestion on how to solve it: Every component
may sublcass Component.onRender(MarkupStream) and/or
Component.onComponentTag(ComponentTag). Both methods make the current
tag available for change and actually quite some components extend
onComponentTag to make sure assumptions are met. However that is
limited to specific components and not a global listener which can be
applied to *any* component. But I think we could quite easily
accomplish that by allowing for an Application to register
implementations of of the interface below. It'd be up to the
implementation if what it wants to do is dependent on the component
type or its markup and react accordingly.
pulic interface IOnComponentRenderListener
{
void onComponentRender(Component, ComponentTag)
}
With respect to wicket:message such as listener could be registered by
default and we are done. What do you think?
Juergen
On 9/19/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
> On 9/19/06, Juergen Donnerstag <[EMAIL PROTECTED]> wrote:
> > You are mixing things here. Markup tags become component tags if they
> > have a wicket:id. This is the only rule. <wicket:xxx > because by
> > default it doesn't have a wicket:id gets an id automatically
> > (<auto>-xxx) assigned for the markup tag to become a component tags.
> > The same happens to autolinks, <body> etc and it happens at markup
> > load time and hence just once per component *type*.
> >
> > While rendering a component *instance* the resolvers are applied and
> > in case of <span wicket:message="myMessage" wicket:id="<auto>-1234"> a
> > resolver could localize an attributes values.
>
> Maybe I'm looking at the wrong place, but I thought we were talking
> about IComponentResolver, which is used in
> MarkupContainer.renderNext(MarkupStream) only if a component with the
> provided id could not be found.
>
> What I understand from looking at the code is this:
>
> <input type="submit" value="foo" wicket:message="value=mykey" />
>
> could work, as it could be given an id, thus making it a component
> tag, but as it couldn't be resolved, it would be located by a
> component resolver. This would work perfect for our purposes. However,
> this:
>
> <input wicket:id="myButton" type="submit" value="foo"
> wicket:message="value=mykey" />
>
> Would not, as it is a regular component that would be resolved by just
> asking the container (MarkupContainer:1252). It would not go through
> any component resolving and thus would never have it's attributes
> touched by it, correct?
>
> Eelco
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Wicket-develop mailing list
> Wicket-develop@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wicket-develop
>
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Wicket-develop mailing list
Wicket-develop@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-develop
