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.
Nick
