Module "JSP support"

[Antonio Petrelli <an...@gmail.com>]

Hi
Just a question: do you think that adding a module for JSP support
could be useful?
And if your answer is yes, do you think that separating the JSP
support could be a good step?  What I have in mind is that supporting
JSP is like supporting any other templating language.
Before making any change I would like some feedback.

Thoughts?
Antonio

Re: Module "JSP support"

["David H. DeWolf" <dd...@apache.org>]

Nathan Bubna wrote:
> +1 for having a roadmap to coordinate efforts and be able to plan
> ahead a bit.  we can throw one up on the wiki.
> 

+1

> +1 for doing an alpha release that includes the jsp/tags stuff.
> pulling out the jsp stuff is a feature subtract to the core, not a
> feature add.  i think we should roll an alpha release before
> separating things.  once we separate them, then we'll need to release
> two things (the JSP stuff and the core) before Tiles 2.x will be
> usable for most people.  Releases aren't that hard, but i agree we
> should prioritize getting one out there (even if we can only label it
> as alpha).
> 

+1

> if Antonio wants to start pulling the JSP stuff out, we can always
> create a 2.0.x branch for the alpha release and let him work on the
> head.

+0

> 
> On 1/29/07, Greg Reddin <gr...@gmail.com> wrote:
>> I do think our highest priority right now should be moving towards a
>> release.  If this module separation can be done without hindering that 
>> goal,
>> then I'm cool with it.  However, we were thinking the introduction of the
>> container would be the last big feature add before we try to release.  
>> So it
>> leads me to wonder how many refactors/feature adds will we do before 
>> we roll
>> it?
>>
>> I think if Antonio (and whoever else gets involved) can get the JSP 
>> module
>> separated out pretty quickly, then we should do it and start immediately
>> into the release process (whatever that ends up being).  If it looks 
>> to be a
>> big deal, then we should just go ahead and roll a 2.0.0 and do this in 
>> 2.1,
>> IMO.
>>
>> The bottom line is that I think we need a roadmap and to try to stick 
>> to it
>> as much as possible.  Do we agree on that approach?
>>
>> Greg
>>
>>
> 

Re: Module "JSP support"

[Antonio Petrelli <ap...@apache.org>]

Nathan Bubna ha scritto:
> if Antonio wants to start pulling the JSP stuff out, we can always
> create a 2.0.x branch for the alpha release and let him work on the
> head.

You word-thief! :-) That was exactly what I wanted to say now.
Anyway there's still the extra effort of an, eventual, merge. Probably 
this separation can wait, but I think that at least a JIRA component can 
be created.

Antonio

Re: Module "JSP support"

[Nathan Bubna <nb...@gmail.com>]

+1 for having a roadmap to coordinate efforts and be able to plan
ahead a bit.  we can throw one up on the wiki.

+1 for doing an alpha release that includes the jsp/tags stuff.
pulling out the jsp stuff is a feature subtract to the core, not a
feature add.  i think we should roll an alpha release before
separating things.  once we separate them, then we'll need to release
two things (the JSP stuff and the core) before Tiles 2.x will be
usable for most people.  Releases aren't that hard, but i agree we
should prioritize getting one out there (even if we can only label it
as alpha).

if Antonio wants to start pulling the JSP stuff out, we can always
create a 2.0.x branch for the alpha release and let him work on the
head.

On 1/29/07, Greg Reddin <gr...@gmail.com> wrote:
> I do think our highest priority right now should be moving towards a
> release.  If this module separation can be done without hindering that goal,
> then I'm cool with it.  However, we were thinking the introduction of the
> container would be the last big feature add before we try to release.  So it
> leads me to wonder how many refactors/feature adds will we do before we roll
> it?
>
> I think if Antonio (and whoever else gets involved) can get the JSP module
> separated out pretty quickly, then we should do it and start immediately
> into the release process (whatever that ends up being).  If it looks to be a
> big deal, then we should just go ahead and roll a 2.0.0 and do this in 2.1,
> IMO.
>
> The bottom line is that I think we need a roadmap and to try to stick to it
> as much as possible.  Do we agree on that approach?
>
> Greg
>
>

Re: Module "JSP support"

[Greg Reddin <gr...@gmail.com>]

I do think our highest priority right now should be moving towards a
release.  If this module separation can be done without hindering that goal,
then I'm cool with it.  However, we were thinking the introduction of the
container would be the last big feature add before we try to release.  So it
leads me to wonder how many refactors/feature adds will we do before we roll
it?

I think if Antonio (and whoever else gets involved) can get the JSP module
separated out pretty quickly, then we should do it and start immediately
into the release process (whatever that ends up being).  If it looks to be a
big deal, then we should just go ahead and roll a 2.0.0 and do this in 2.1,
IMO.

The bottom line is that I think we need a roadmap and to try to stick to it
as much as possible.  Do we agree on that approach?

Greg

Re: Module "JSP support"

["David H. DeWolf" <dd...@apache.org>]

Nathan Bubna wrote:
> On 1/29/07, David H. DeWolf <dd...@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 <nb...@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
>> >
>>
> 

Re: Module "JSP support"

[Nathan Bubna <nb...@gmail.com>]

On 1/29/07, David H. DeWolf <dd...@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 <nb...@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
> >
>

Re: Module "JSP support"

["David H. DeWolf" <dd...@apache.org>]

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

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.

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?


David



Antonio Petrelli wrote:
> 2007/1/29, Nathan Bubna <nb...@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
> 

Re: Module "JSP support"

[Nathan Bubna <nb...@gmail.com>]

On 1/29/07, Antonio Petrelli <an...@gmail.com> wrote:
> 2007/1/29, Nathan Bubna <nb...@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).

This is true, but Struts 2 is explicitly a framework, and integration
of components for users' convenience is arguably the defining aspect
of a "framework".    Tiles, however, is much more a "view component"
than a framework.  Components should not, IMHO, take pains to concern
themselves with integrating themselves with other components.  They
may use other components internally and should certainly provide
interfaces for easy integration with others, but the integration with
other components should be at best a secondary concern.

That said, VelocityTools also aims to be a "view component", not a
full framework.  The VelocityStruts integration would have been better
developed at Struts in an ideal world, but  that path was not open to
us at the time.  Because of this, already there is some integration of
view components for users' convenience happening, and it seems healthy
enough.  If we do want to consider moving Tiles+Velocity integration
into the Tiles project alongside the Tiles+JSP module, i would be open
to it.   It would at least save me the trouble of having both a
TilesTool and a Tiles2Tool in VelocityTools. :)

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

Yeah, David's work is going to make Tiles2+Velocity quite easy.  It
should not be hard to develop or maintain.

> Just my 2 eurocents
> Antonio
>

Re: Module "JSP support"

[Antonio Petrelli <an...@gmail.com>]

2007/1/29, Nathan Bubna <nb...@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

Re: Module "JSP support"

[Nathan Bubna <nb...@gmail.com>]

I like the idea a lot because i suspect it will likely make it easier
for me to integrate Tiles without worrying about JSP specific things
creeping into the core of Tiles.

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.

But i am +1 for adding a module for JSP support, just to encourage
cleaner, less JSP specific code.

On 1/29/07, Antonio Petrelli <an...@gmail.com> wrote:
> Hi
> Just a question: do you think that adding a module for JSP support
> could be useful?
> And if your answer is yes, do you think that separating the JSP
> support could be a good step?  What I have in mind is that supporting
> JSP is like supporting any other templating language.
> Before making any change I would like some feedback.
>
> Thoughts?
> Antonio
>