tiles-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David H. DeWolf" <ddew...@apache.org>
Subject Re: Module "JSP support"
Date Mon, 29 Jan 2007 17:39:35 GMT

Nathan Bubna wrote:
> 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.

I'm perfectly fine with that definition.  And if others do too - let's 
roll one :)

>> 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
>> >

View raw message