tiles-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nathan Bubna" <nbu...@gmail.com>
Subject Re: Module "JSP support"
Date Mon, 29 Jan 2007 17:28:43 GMT
On 1/29/07, David H. DeWolf <ddewolf@apache.org> wrote:
> I like the idea, but I do wonder if this will open up a can of worms
> that we'll always have to deal with -- whether or not we should develop
> integration with other template engines as part of the Tiles project.

thinking about this more...  i think i would support integration with
other template engines only under the following conditions:

1) We have committers who will develop/maintain them.  I.e.  we don't
create a Tiles+MyFavoriteTemplateEngine upon request.

2) They stay separate projects.  This way if they fall dormant, they
don't encumber releases of other, good code.

> My preference is to keep Tiles small, to keep it to the framework and
> jsp integration, while at the same time making sure the framework has
> adequate hooks for other template languages.

This would also be fine with me.

> Also, I'm assuming that would mean that the tags would be part of the
> tiles-jsp module.  Now that the container has been introduced we should
> be able to make the cut fairly easily.  I can think of a couple of
> gotcha's off the top of my head, but nothing we can't get past.  In
> fact, this exercise would probably be a good test of how well we've done.

and it would prevent future jsp dependency creep.  i like that part too. :)

> I'm 50/50, I could see it going either way. I'd just like to get an
> alpha release out sooner rather than later.  How does this decision
> effect that?

Precious little should affect doing a release that we deem "alpha"
quality.  To me, the alpha label means only that the code compiles and
mostly runs.   It doesn't promise any sort of backward or forward
compatibility and the public interfaces may change freely without need
for a deprecation cycle.   Alphas are for people to try out, not for
people to depend on.

In other words, we should be able to roll out an alpha anytime we
want, regardless of what major changes may be in the pipeline.

>
> David
>
>
>
> Antonio Petrelli wrote:
> > 2007/1/29, Nathan Bubna <nbubna@gmail.com>:
> >> However, we then must ask the question of whether we're going to allow
> >> modules for other template engines too?  I don't think we have to
> >> answer yes to that, though.  JSP, for all its problems, is the
> >> "standard" so it is easy to say we will only maintain support for
> >> Tiles+JSP here.  Then we can leave Tiles+Velocity or Tiles+Freemarker
> >> to be developed elsewhere.  As the VelocityTools lead, i really don't
> >> care much either way.
> >
> > I think that the part of VelocityTools for Tiles is more connected to
> > Tiles than to Velocity. If you think about Struts 2, the FreeMarker
> > integration is just inside Struts 2 itself (I think it's a module,
> > correct me if I am wrong).
> > I agree that JSP will remain the base for all development, but since
> > David made a great work on removing the dependencies between the
> > view/template technology and the rendering, the porting to Velocity
> > and FreeMarker will be easy (at least for Velocity/Freemarker experts
> > :-) ) and, I suppose, the best place to put integration code is inside
> > a Tiles module. You just have not a "JSPTools" for Struts :-)
> >
> > Just my 2 eurocents
> > Antonio
> >
>

Mime
View raw message