tiles-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicolas LE BAS <m...@nlebas.net>
Subject Re: Tiles 3 project structure
Date Wed, 19 Oct 2011 17:34:25 GMT
On 11-10-19 04:12 AM, Antonio Petrelli wrote:
> 2011/10/18 Nicolas LE BAS<mail@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.

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 

> 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 :)


View raw message