2007/4/11, David H. DeWolf <[EMAIL PROTECTED]>:
Greg Reddin wrote: > On 4/11/07, David H. DeWolf <[EMAIL PROTECTED]> wrote: > It does seem that TilesDecorationFilter and TilesDispatchServlet are > misplaced. Personally I think all these things should be in tiles-core > instead of tiles-api. Personally, also, I like the organization of > tiles-api and would propose we just move those classes there. I was thinking the opposite. . .that we should move all of the other entry points into the API. If we have an api with no entry points, why do we have an API? It's essentially useless.
Mmm, TilesDispatchServlet and TilesDecorationFilter does not seem like "entry points" to me, but something like "extension", or "utilities", or "extras". The possible entry point probably are TilesServlet and InitContainerTag, but I am wondering what is the entry point for a portlet environment... What do you think of a separation depending on the used technology? (To be done in a 2.1.x release). What I mean is: tiles-api: all base interfaces and classes (container, attribute, access classes) tiles-core: basic implementation of the api (definitions factory and its implementations, basic container, all the classes that permit the basic container to work). tiles-servlet: classes that allow the use of Tiles in a servlet environment (TilesServlet, TilesFilter, TilesListener, TilesDispatchServlet, TilesDecorationFilter, Tiles context classes for servlets). tiles-portlet: like "tiles-servlet" but with the use in a portlet environment. tiles-jsp: like "tiles-servlet" but with the use in a JSP environment (including taglibs). tiles-compat: the "infamous" compatibility layer for Tiles 1 definition files and tags. Now, with the help of Maven's assembly plugin, we could build a "tiles-all.jar" file that collects all that stuff in a single jar, ready for the use under a non-mavenized webapp.
> So, I'm not against the changes we're talking about. I think they are > good, > but add Antonio's compatibility layer and we could be looking at more > months > of alpha before things start to stabilize. I'm not sure anyone proposed that the compatibility layer is required for a beta or ga release.
In fact I was thinking of a 2.1.x version. Antonio
