struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <craig...@apache.org>
Subject Re: RE: Tiles Refactorings for 1.1 compatability
Date Wed, 16 Oct 2002 21:33:16 GMT


On Wed, 16 Oct 2002, Ted Husted wrote:

> Date: Wed, 16 Oct 2002 16:53:48 -0400
> From: Ted Husted <husted@apache.org>
> Reply-To: Struts Developers List <struts-dev@jakarta.apache.org>,
>      ted@husted.com
> To: Struts Developers List <struts-dev@jakarta.apache.org>
> Subject: Re: RE: Tiles Refactorings for 1.1 compatability
>
> If Steve, or anyone else, would like to start putting together a roadmap for Struts 1.1,
1.2, and 1.2+ (formerly
> 1.1+), I'll be happy to post it on the site and maintain it. It doesn't have too be XML,
I can take it off the
> list if that's what it takes.
>

IMHO, any rational roadmap for post-1.1 is going to have to lump proposed
changes into at least two buckets:

* Those that can be implemented on Servlet 2.2 / JSP 1.1,
  including refactoring of existing functionality (but
  with a continued emphasis on backwards compatibility).

* Those that require updating the minimum platform to
  Servlet 2.3 / JSP 1.2 (JSTL and JavaServer Faces will
  both fall into this camp, as would any refactoring that
  depended on being able to use Filters).

My personal interests are in the latter area, but I wouldn't be surprised
to see many folks wanting to work on the former.  Maybe we can
colloquially think about categorizing things in the appropriate buckets,
and think about calling them Struts 1.2.x and Struts 2.0.x (with the ".x"
representing milestone releases like Tomcat 4.1 and Apache httpd do it)?

> -T.
>

Craig


>
> 10/16/2002 4:47:29 PM, "Byrne, Steven" <sbyrne@dorado.com> wrote:
>
> >I would think that before Ted or anyone can answer the question of
> >whether to wait until 1.2, a clear roadmap of near term future releases,
> >including features and functionality lists for each release, be
> >published.  Right now, saying that it's ok to wait until 1.2 is pretty
> >much meaningless without a time estimate based on the amount of content
> >going into 1.2 (or even a definition of what 1.2 is).
> >
> >When I talked with Craig a few months back, he was thinking that the
> >next release of Struts would be focused on incorporating JSF related
> >functionality; I don't know if that's still the case.  If it is, that
> >would make for a much more significantly challenging release, and thus
> >would extend the time that people would have to wait for a fully working
> >tiles/validator version of Struts.
> >
> >Steve
> >
> >> -----Original Message-----
> >> From: Ted Husted [mailto:husted@apache.org]
> >> Sent: Wednesday, October 16, 2002 1:34 PM
> >> To: Struts Developers List
> >> Subject: Re: Tiles Refactorings for 1.1 compatability
> >>
> >>
> >> 10/16/2002 4:03:01 PM, "V. Cekvenich"
> >> <vicc@users.sourceforge.net> wrote:
> >> >Can you wait till 1.2 Ted?
> >>
> >> All that I'm saying is that we should support specifying a
> >> list of struts-config files, as we do for the
> >> validator and tiles configs. This way people could split up
> >> the config files without buying into modules. Craig
> >> wanted to pursue modules to support URI-independance, but now
> >> that we done that I think we should support the
> >> obvious solution too.
> >>
> >> The only other thing I meant to say is that if we're going to
> >> call Tiles 1.1 compliant, it should have the same
> >> contextRelative property we see on the ActionForward. I
> >> didn't mean to say that there should be a gobal Tiles
> >> config or anything like that.
> >>
> >> In both cases, I'm just saying we should consistently
> >> complete what we started. Beta are for finding oversights
> >> and inconsistencies as well as malfunctions.
> >>
> >> But if everyone is on board for cutting a quick 1.2 release
> >> to catch issues we are postponing now, I'm willing
> >> to play along (again).
> >>
> >> My only concern is that post 1.1, we will also want to talk
> >> about things like servlet 2.3 support. My concern is
> >> that those discussions might become an excuse to postpone
> >> finishing what we (only) started here. But with more
> >> committers on board, perhaps we can afford to work on more
> >> than one code stream now.
> >>
> >> -Ted.
> >>
> >>
> >>
> >> --
> >> To unsubscribe, e-mail:
> >> <mailto:struts-dev-unsubscribe@jakarta.apache.org>
> >> For additional commands, e-mail:
> >> <mailto:struts-dev-help@jakarta.apache.org>
> >>
> >>
> >
> >--
> >To unsubscribe, e-mail:   <mailto:struts-dev-unsubscribe@jakarta.apache.org>
> >For additional commands, e-mail: <mailto:struts-dev-help@jakarta.apache.org>
> >
> >
>
>
>
>
>
>
> --
> To unsubscribe, e-mail:   <mailto:struts-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:struts-dev-help@jakarta.apache.org>
>
>


--
To unsubscribe, e-mail:   <mailto:struts-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-dev-help@jakarta.apache.org>


Mime
View raw message