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
tiles-parent).
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:
tiles-autotag
+- 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
+- tiles-request-api
+- tiles-request-XYZ (basically the same as today without the package
'render')
+- tiles-render-XYZ (when applicable)
tiles-eval
+- tiles-eval-api
+- tiles-el
+- tiles-mvel
+- tiles-ognl
tiles-parent
+- 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?
Nick
