2011/10/18 Nicolas LE BAS <[email protected]> > 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). >
It's right. > 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). Oh, you are right. In fact if we want to separate the API from the implementation (even the simplest ones) a new module should be created. > 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. > And instead a JspRequest is 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. > And instead a DispatchRenderer is used. I see your point. > 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. > Great analysis thanks! > > 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. I am not so sure anymore. However it might be a matter of convenience: usually the developer who uses Velocity-based taglibs will use velocity templates. It is unlikely (not impossible) that he/she mixes technologies. Therefore, I think that creating a new module hierarchy will be confusing for users (or not?). > 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. The problem is inside Velocity Tools, in which only the servlet environment (and Struts, but it is out of our scope) is considered. The same is for Freemarker, in which an instance of an extension of the FreemarkerServlet is created inside the renderer. I tried to abstract it as much as possible, but some work on Velocity and Freemarker should be done to gain complete abstraction. In a perfect world, Tiles' request implementation should be used both by Velocity and Freemarker. Notice that currently I am Velocity PMC member, so you will find me there too ;-) Same if I want to write a new taglib for the existing VelocityRequest, which > needs to fetch more information from the AST. Can you elaborate on this? I don't understand what you mean. > > 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. > It seems a great idea. > 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. > Interesting. > > 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. What I did is, in fact, a mixed-up situation, in which I integrated Velocity+Servlet and Freemarker+Servlet. In my mind, I did not want to integrate, say, portlets, since it would mean to create Servlet wrappers around portlet request. Instead, I would prefer to lobby Velocity to adopt the Tiles' request API. > 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. > In fact the project is currently pretty silent. I decided not to develop it anymore, and I am here only to answer questions and, possibly, committing patches. As you might have seen in the mail archives, I believe Tiles made its time and it's becoming useless in a world of thick-client interfaces and servers used as plain data and service providers (e.g in GWT). Antonio P.S. To apply a correct patch to Tiles, probably it's better to use Git, however currently Tiles has not been mirrored as a Git repository. Give me some time to do it.
