Mailing-List: contact dev-help@tiles.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@tiles.apache.org
Received-SPF: pass (herse.apache.org: domain of antonio.petrelli@gmail.com
 designates 64.233.162.224 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition;
        b=M0jUYGfhjfK6w/76VN8R999pMBwSmCW1ICS23ZL8Skc5OYpp4ctJp9PPIH49ut9xeurJIlwnspFYHMPImMA3ATeFwQRI2/Y/bbvh5vxngM4R/DMj+AG8dfU+B8YvE8N1jWLfzTSC6MmOMqOAQNiPyVt6Z4oWdNwCy7pQV0HJMEk=
Message-ID: <aae96ca0704120012x67c34b4kfc2c132997c02c07@mail.gmail.com>
Date: Thu, 12 Apr 2007 09:12:51 +0200
From: "Antonio Petrelli" <antonio.petrelli@gmail.com>
To: dev@tiles.apache.org
Subject: Tiles entry points (WAS: Re: [VOTE] 2.0.3 Release Quality)
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

2007/4/11, David H. DeWolf <ddewolf@apache.org>:
>
>
> Greg Reddin wrote:
> > On 4/11/07, David H. DeWolf <ddewolf@apache.org> 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