tiles-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicolas LE BAS <m...@nlebas.net>
Subject Tiles 3 project structure
Date Tue, 18 Oct 2011 04:44:50 GMT
Hi again,

I've been trying to understand the tiles 3 project structure in order to 
integrate it in the right way. I understand that it's not released nor 
documented, yet. And it's too soon to ask for support on that, but I'd 
like to check if I've understood correctly and perhaps to suggest 
something different.

The current structure revolves around 3 groups of projects:
- tiles-request, including the abstract request model and 
implementations for jsp, servlet, portlet, freemarker and velocity.
- tiles-parent (and tiles-eval) include the engine (tiles-core + 
tiles-template) and a number of "glue" projects for all implementations 
around here.
- tiles-autotag generates the necessary code to process the taglib in 
jsp, velocity and freemarker (note that the generated code goes into 

I must say that it's a huge improvement compared to tiles 2.2, but I 
still find it a bit messy. Perhaps because I don't know it well enough, yet.

But here is how I see it: Tiles is a layout engine, and does nothing by 
itself. It receives rendering requests from other techonologies, and 
delegates the rendering to other technologies (sometimes the same). 
Therefore it requires two groups of adapters:
- one for the requests received through taglibs or servlet or direct 
calls to the container. Those adapters are responsible for converting 
the user's request into a uniform Request abstraction.
- one for the orders sent to the rendering technologies, through the 
Renderer interface.

With the current layout, Request and Renderer are placed together in the 
same package when they share the same technology. It took me a while to 
understand that it's a bridge pattern and the Request and Renderer 
hierarchies are completely unrelated. But of course I have to admit that 
people usually use the same technology on the request side and the 
rendering side (even if I don't), so perhaps it's good for them to have 
a single jar file.

The autotags are much less clear. For a given techology, say freemarker, 
we have 4 projects: the "request" described above, the "autotag" (a tag 
generator), "autotag-runtime" with abstract classes that create the 
Requests, and a "glue" project in tiles-parent that hosts the generated 
tags. That's at least one project too many, because you can't possibly 
use the "glue" and "autotag-runtime" without each other.

Therefore I'd like to suggest the following, for clarity and because it 
would make it easier to explain in the docs:

+- maven-autotag-plugin
+- tiles-autotag-generator (rename for tiles-autotag-core)
+- tiles-autotag-core (rename for tiles-autotag-core-runtime: use the 
shorter alternative for the runtime libs)
+- tiles-autotag-XYZ-generator (rename for tiles-autotag-XYZ)
+- tiles-autotag-XYZ merging tiles-autotag-XYZ-runtime and tiles-XYZ.

+- tiles-request-api
+- tiles-request-XYZ (basically the same as today without the package 
+- tiles-render-XYZ (when applicable)

+- tiles-eval-api
+- tiles-el
+- tiles-mvel
+- tiles-ognl

+- tiles-api
+- tiles-core
+- tiles-template
+- tiles-compat
+- tiles-extra

Eventually the tiles-request-XYZ could be merged with tiles-autotag-XYZ 
when it's small enough; there's no request coming to tiles from a JSP 
except from a taglib.

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?

What do you think?


View raw message