On 11-10-19 04:12 AM, Antonio Petrelli wrote:
2011/10/18 Nicolas LE BAS<m...@nlebas.net>
There's still some way to go however. Right now autotag depends on the
whole tiles-request through static methods.
Let's say for instance that I want to write a new VelocityRequest that
doesn't rely on servlets: I can't reuse the existing
autotag-velocity-runtime, since it refers to the existing
tiles-request-velocity. So I have to write a new autotag-velocity-runtime,
and thus a new autotag-velocity, and thus a new maven plugin.
The problem is inside Velocity Tools, in which only the servlet environment
(and Struts, but it is out of our scope) is considered. The same is for
Freemarker, in which an instance of an extension of the FreemarkerServlet is
created inside the renderer.
That's only because we're using Velocity Tools. I'm using a custom
renderer that calls the VelocityEngine directly (the way autotag does),
but there's no velocity-based servlet around it. Same for freemarker. If
I need a servlet, I can use TilesDispatchServlet (well, I'll tell the
whole truth: I'm actually using Spring MVC's DispatcherServlet).
The drawback is that configuration gets complicated, but spring helps.
Same if I want to write a new taglib for the existing VelocityRequest, which
needs to fetch more information from the AST.
Can you elaborate on this? I don't understand what you mean.
Unfortunately, no, I can't. I was looking for an example of extending an
existing implementation, but I don't actually need to. It's a purely
theoretical example, and perhaps a bad one.
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.
Well, here's what I'm coming up with.
I couldn't find a way to decouple autotag-xxx-runtime from request-xxx
without removing something from autotag. So instead 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.
In fact the project is currently pretty silent. I decided not to develop it
anymore, and I am here only to answer questions and, possibly, committing
patches. As you might have seen in the mail archives, I believe Tiles made
its time and it's becoming useless in a world of thick-client interfaces and
servers used as plain data and service providers (e.g in GWT).
I think I see your point, but you're actually making it against
server-based navigation (i.e. struts or JSF), not against declarative
layout engines like tiles.
Even thick clients have issues with complex layouts (perhaps even more
than thin clients) and they're all shifting from programmatic layout to
declarative: since you mention GWT, there's uiBinder. I don't think that
tiles is much different in nature.
Anyway I won't blame you for your loss of interest, you're far from
alone in that :)
Nick.
