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 Tue, 18 Oct 2011 19:08:18 GMT
On 11-10-18 03:40 AM, Antonio Petrelli wrote:
> The reasoning that at that time I did is that:
> servlets and portlets need only the "request" part;
> JSP, velocity and freemarker need both the request and the render part.

Agreed, even if there is no JspRenderer as such. I think it's called 
DispatchRenderer and resides in tiles-request-api (but I'll ask about it 
later, perhaps).
And there are DefinitionRenderer and the trivial StringRenderer, too. 
These need only the "render" part (unless we want to expose the 
definition attributes to the ELs, but that would be for later, too).

> In a previous thought of mine, I decided to create a "tiles-render" project.
>   However I noticed that having tiles-velocity-render had no sense without
> its "request" counterpart. Therefore I decided to put them together.

I believe the current state of tiles 3 would allow both of these scenarii:
- TilesDispatchServlet invokes a tile definition with a JSP template, 
that includes a velocity template as an attribute: VelocityRenderer is 
invoked while no VelocityRequest gets created.
- VelocityViewServlet calls a velocity template containing 
insertDefinition, and the definition is implemented in pure JSP. A 
VelocityRequest is created and VelocityRenderer is never called.

org.apache.tiles.velocity.render makes no reference to VelocityRequest 
whatsoever, only to the abstract Request interface. Technically you only 
need VelocityRequest when you use the velocity version of the taglib.

But I admit, if people need velocity and tiles, they usually need the 
taglib, too, and no JSP. And the interfaces Request and Renderer 
undeniably belong together.

> Ok for the rename. However, since autotag and Tiles have to be separate
> projects (there is not a single reference to Tiles inside -runtime projects)
> the fusion of tiles-xxx and tiles-autotag-xxx-runtime is out of the
> question.

Ok, I missed that part, I understand things better now, thanks.

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.

Same if I want to write a new taglib for the existing VelocityRequest, 
which needs to fetch more information from the AST.

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.

Coming back to my VelocityRequest example again, I should just have to 
provide a couple of classes as a parameter to the existing maven plugin 
to generate the Directives.

I think autotag would be easier to use if it only relies on 
tiles-request-api and the native apis (javax.servlet.jsp.*, 
freemarker.*, org.apache.velocity.*), and easier to adopt that way.

>> Of course I realize I'm the newcomer here; you guys have probably discussed
>> all of this already, and perhaps reached similar conclusions (or not...).
>> But it helps me understanding how things are, and well, perhaps I can help,
>> who know?
> You are indeed helping! In fact this is the first discussion about the
> structure. In the past it was a simple one-man show (with the one-man being
> me ;-) ).

Tiles has been indeed the most undervalued project in past decade. It 
was the most useful part of struts, but when the focus shifted away from 
struts, tiles was forgotten. Since then struts as been outpaced by 
spring and JSF, however tiles is still the easiest and most elegant way 
to organize a complex web site, and it works not only with struts, but 
with every current MVC technology.

Thanks for keeping it alive and kicking all this time. Helping is always 
a pleasure.


View raw message