2011/10/18 Nicolas LE BAS <m...@nlebas.net> > 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. >
You're right, but notice that tiles-request and tiles-autotag should become separate projects (at least I hope this).รน > > 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.Ho w 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. 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. 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. > 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. tiles-request > +- tiles-request-api > +- tiles-request-XYZ (basically the same as today without the package > 'render') > +- tiles-render-XYZ (when applicable) > See my comment above. > > tiles-eval > +- tiles-eval-api > +- tiles-el > +- tiles-mvel > +- tiles-ognl > +1 > tiles-parent > +- tiles-api > +- tiles-core > +- tiles-template > +- tiles-compat > +- tiles-extra > The autotag-generated project must be included for the reasons above. > 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. > I agree, replacing tiles-autotag-XYZ with tiles-autotag-XYZ-runtime. > 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 ;-) ). Thanks Antonio P.S. Once these discussions are settled a bit, please post all your patches in JIRA.
