Ok, I've been debating this in my head, and trying to come up with a few
use cases for using the api without any entry points. Since I've come
up with a few, I see your point and think we should move the Filter and
Servlet into core.
I'd personally also like to see us repackage all of the Servlets,
Listeners, Filters, etc. . . into a single web package so that we don't
have on class packages. . .but that's just a personal preference.
Antonio Petrelli wrote:
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
