> >> We need a new abstraction here to decouple autotag further. I'll think
> >> about it, but I believe inheritance is the restricting part in the current
> >> implementation. Perhaps a Factory interface, or possibly reflection, would
> >> work better.
> >>
> > It seems a great idea.
>
> [snip] I'm decoupling
> autotag-xxx from autotag-xxx-runtime. Now if I want to extend it, I just
> have to write a new runtime and call the existing maven plugin.
>
> Details:
> The generated classes are calling on runtime for 3 purposes: creating a
> Request, creating a ModelBody, and getting the tags parameters. So I
> create that interface in autotag-core-runtime:
> interface Runtime {
> Request createRequest();
> ModelBody createModelBody();
> Object getParameter(String name, Object defaultValue);
> }
> Now the generated classes can refer to that interface instead of direct
> references to the classes in autotag-xxx-runtime. With one exception: we
> have to call the right implementation. That's done in 2 steps:
> - the name of the implementation class is passed as a parameter to the
> maven plugin, and included in the generated classes. It is the only
> reference to autotag-xxx-runtime, so I can replace the whole
> runtime-package if I need to.
> - the implementation class needs to be fed the details of the tag that
> is calling it. Therefore I make it implement the relevant tag interface
> (either SimpleTagSupport, Directive or TemplateModelDirective, depending
> on the technology) and I call it from my actual tag as if it were a
> wrapped object, using the template engine's api. That way it gets access
> to everything:
>
> runtime = new VelocityRuntime();
> if(runtime instanceof Directive) {
> ((Directive) runtime).render(context, writer, node);
> }
> Request request = runtime.createRequest();
>
> That way autotag depends only on its core packages, tiles-request-api,
> and the native apis. autotag-xxx-runtime still depends on
> tiles-request-xxx, but nothing depends on it, so it can be replaced easily.
>
> I've got a version that compiles and looks good, but I still have some
> (tedious) work on updating the tests. I'd like your opinion before I
> proceed. Antonio, any objections to this before i commit the patch? It looks like a welcome addition to me, the thorns: specifying impl class in plugin, and casting to render; seem minor compared to the benefits in separating the code apart. ~mck -- "There are only two ways to live your life. One is as though nothing is a miracle. The other is as if everything is." Albert Einstein | www.semb.wever.org | www.sesat.no | tech.finn.no | http://xss-html-filter.sf.net
signature.asc
Description: This is a digitally signed message part
