if this does work generically, it's totally cool.
although we will want to continue to debate how much and/or how to open up our namespaces to users...
one thought: wouldn't it be better to call it Container.resolveComponentName()?
also, if ComponentNameResolver is an interface, it should be IComponentNameResolver in wicket style.
Juergen Donnerstag wrote:
May be I have a solution to the [body} and [autolink] problem of having Border related code in Container autolink related code in MarkupParser and ComponentTag.
The idea is around what I called a ComponentNameResolver. It is a simple interface with just one mehtod: handleUnknownComponentName(...). ComponentNameResolver is may be a little bit misleading, as it not only does the mapping of componentName to Component. handleUnknownComponentName() is also responsible to call render() on that component. That was necessary to support [body].
Lets start with [body]. Container.renderNext() frst tries to find a Component within the component hierachie with the componentName (let us ignore autolink for a moment). If not foud, it'll test for [body] and if its not, than throw an exception. I introduced a protected methd called Container.handleUnknownComponentName() which default implementation simply return false. Border (or any other Container) may subclass it and provide its own implmenentation. I just copied the [body] code from Container into Boder.handleUnknownComponentName(). ready.
It was obviuos to cover [autolink} the same way. There was only one problem: Autolink is not a component. I solved it by adding a List of ComponentNameResolvers to AppSettings. This way anybody may add his own (static) Resolvers. Container.renderNext() iterates through this list prior to throwing an excpetion (the exception will only be thrown if no Resolver is able to handle the componentName).
Container.renderNext() now look like below. No more [body], no more autolink related code. I remove the autolink code from MarkupParser and ComponentTag and moved it into an AutolinkComponentNameResolver. I run all examples and the test available. It really seems to work.
The order of execution is 1) try to find a Component with componentName 2) try all static ComponentNameResolvers from AppSettings 3) try the Container's (or any subclass) .handleUnknownComponentName()
What do think?
Juergen
..... // Get the component for the component name from the given container Component component = get(componentName);
// Failed to find it?
if (component != null)
{
component.render(cycle);
}
else {
final List componentNameResolvers =
this.getApplicationSettings().getComponentNameResolvers();
final Iterator iter = componentNameResolvers.iterator();
while (iter.hasNext())
{
final ComponentNameResolver resolver =
(ComponentNameResolver) iter.next();
if (resolver.handleUnknownComponentName(cycle,
markupStream, tag, this) == true)
{
return;
}
}
if (handleUnknownComponentName(cycle, markupStream, tag) == false)
{
markupStream.throwMarkupException("Unable to find
component named '" + componentName + "' in " + this);
}
}
------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ Wicket-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-develop
------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ Wicket-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-develop
