You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by hu...@apache.org on 2006/01/21 01:21:00 UTC
svn commit: r370938 [29/50] - in /struts: action/trunk/
action/trunk/conf/java/ action/trunk/src/java/org/apache/struts/
action/trunk/src/java/org/apache/struts/action/
action/trunk/src/java/org/apache/struts/chain/
action/trunk/src/java/org/apache/str...
Modified: struts/action/trunk/xdocs/roadmap.xml
URL: http://svn.apache.org/viewcvs/struts/action/trunk/xdocs/roadmap.xml?rev=370938&r1=370937&r2=370938&view=diff
==============================================================================
--- struts/action/trunk/xdocs/roadmap.xml (original)
+++ struts/action/trunk/xdocs/roadmap.xml Fri Jan 20 16:19:02 2006
@@ -18,484 +18,599 @@
-->
<document>
-<properties>
- <title>Roadmap</title>
-</properties>
-
-<body>
-
-<section name="Development Roadmap">
-<a name="roadmap"/>
-
-<a name="scope"/>
-<subsection name="Scope">
-
- <p>
- This document outlines some of changes we expect to
- see in future releases of Struts Action Framework and related subprojects.
- </p>
-
- <p>
- This document is provided for discussion purposes only.
- All releases and changes to the codebase are subject to
- <a href="http://struts.apache.org/bylaws.html">a vote</a> of the
- <a href="http://struts.apache.org/volunteers.html#pmc">Struts PMC</a>.
- </p>
-
- <p>
- An outline of the enhancements proposed here can be found on the
- <a href="milestones.html">Milestones</a> page.
- </p>
-
- </subsection>
-
- <a name="Bugzilla"/>
- <subsection name="Bugzilla Queries">
-
- <p>
- The Struts development community uses the
- <a href="http://issues.apache.org/bugzilla">
- Apache Bug Database</a> (Bugzilla) to manage problem reports
- and enhancement suggestions.
- For your convenience, here are some common Bugzilla queries:
- </p>
-
- <ul>
- <li><a href="http://issues.apache.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&product=Struts&order=bugs.bug_id">Open reports</a></li>
- <li><a href="http://issues.apache.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&email1=&emailtype1=substring&emailassigned_to1=1&email2=&emailtype2=substring&emailreporter2=1&bugidtype=include&bug_id=&changedin=&votes=3&chfieldfrom=&chfieldto=Now&chfieldvalue=&product=Struts&short_desc=&short_desc_type=allwordssubstr&long_desc=&long_desc_type=allwordssubstr&bug_file_loc=&bug_file_loc_type=allwordssubstr&keywords=&keywords_type=anywords&field0-0-0=noop&type0-0-0=noop&value0-0-0=&cmdtype=doit&order=Bug+Number">Open reports with at least 3 votes</a></li>
- <li><a href="http://issues.apache.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=Blocker&bug_severity=Critical&bug_severity=Major&bug_severity=Normal&bug_severity=Minor&email1=&emailtype1=substring&emailassigned_to1=1&email2=&emailtype2=substring&emailreporter2=1&bugidtype=include&bug_id=&changedin=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&product=Struts&short_desc=&short_desc_type=allwordssubstr&long_desc=&long_desc_type=allwordssubstr&bug_file_loc=&bug_file_loc_type=allwordssubstr&keywords=&keywords_type=anywords&field0-0-0=noop&type0-0-0=noop&value0-0-0=&cmdtype=doit&order=bugs.bug_id">Open problem reports</a>
+ <properties>
+ <title>Roadmap</title>
+ </properties>
+
+ <body>
+
+ <section name="Development Roadmap">
+ <a name="roadmap"/>
+
+ <a name="scope"/>
+ <subsection name="Scope">
+
+ <p>
+ This document outlines some of changes we expect to
+ see in future releases of Struts Action Framework and
+ related subprojects.
+ </p>
+
+ <p>
+ This document is provided for discussion purposes only.
+ All releases and changes to the codebase are subject to
+ <a href="http://struts.apache.org/bylaws.html">a vote</a>
+ of the
+ <a href="http://struts.apache.org/volunteers.html#pmc">
+ Struts PMC</a>
+ .
+ </p>
+
+ <p>
+ An outline of the enhancements proposed here can be found
+ on the
+ <a href="milestones.html">Milestones</a>
+ page.
+ </p>
+
+ </subsection>
+
+ <a name="Bugzilla"/>
+ <subsection name="Bugzilla Queries">
+
+ <p>
+ The Struts development community uses the
+ <a href="http://issues.apache.org/bugzilla">
+ Apache Bug Database</a>
+ (Bugzilla) to manage problem reports
+ and enhancement suggestions.
+ For your convenience, here are some common Bugzilla
+ queries:
+ </p>
+
<ul>
- <li><a href="http://issues.apache.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&product=Struts&bug_severity=Blocker&bug_severity=Critical&bug_severity=Major&order=bugs.bug_id">major problem reports</a></li>
- <li><a href="http://issues.apache.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&product=Struts&bug_severity=Blocker&bug_severity=Normal&bug_severity=Minor&order=bugs.bug_id">normal/minor problem reports</a></li>
+ <li>
+ <a href="http://issues.apache.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&product=Struts&order=bugs.bug_id">
+ Open reports</a>
+ </li>
+ <li>
+ <a href="http://issues.apache.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&email1=&emailtype1=substring&emailassigned_to1=1&email2=&emailtype2=substring&emailreporter2=1&bugidtype=include&bug_id=&changedin=&votes=3&chfieldfrom=&chfieldto=Now&chfieldvalue=&product=Struts&short_desc=&short_desc_type=allwordssubstr&long_desc=&long_desc_type=allwordssubstr&bug_file_loc=&bug_file_loc_type=allwordssubstr&keywords=&keywords_type=anywords&field0-0-0=noop&type0-0-0=noop&value0-0-0=&cmdtype=doit&order=Bug+Number">
+ Open reports with at least 3 votes</a>
+ </li>
+ <li>
+ <a href="http://issues.apache.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=Blocker&bug_severity=Critical&bug_severity=Major&bug_severity=Normal&bug_severity=Minor&email1=&emailtype1=substring&emailassigned_to1=1&email2=&emailtype2=substring&emailreporter2=1&bugidtype=include&bug_id=&changedin=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&product=Struts&short_desc=&short_desc_type=allwordssubstr&long_desc=&long_desc_type=allwordssubstr&bug_file_loc=&bug_file_loc_type=allwordssubstr&keywords=&keywords_type=anywords&field0-0-0=noop&type0-0-0=noop&value0-0-0=&cmdtype=doit&order=bugs.bug_id">
+ Open problem reports</a>
+ <ul>
+ <li>
+ <a href="http://issues.apache.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&product=Struts&bug_severity=Blocker&bug_severity=Critical&bug_severity=Major&order=bugs.bug_id">
+ major problem reports</a>
+ </li>
+ <li>
+ <a href="http://issues.apache.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&product=Struts&bug_severity=Blocker&bug_severity=Normal&bug_severity=Minor&order=bugs.bug_id">
+ normal/minor problem reports</a>
+ </li>
+ </ul>
+ </li>
+ <li>
+ <a href="http://issues.apache.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&product=Struts&bug_severity=Enhancement&order=Bug+Number">
+ Open enhancement reports</a>
+ <ul>
+ <li>
+ <a href="http://issues.apache.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=Enhancement&email1=&emailtype1=substring&emailassigned_to1=1&email2=&emailtype2=substring&emailreporter2=1&bugidtype=include&bug_id=&changedin=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&product=Struts&short_desc=&short_desc_type=allwordssubstr&long_desc=&long_desc_type=allwordssubstr&bug_file_loc=&bug_file_loc_type=allwordssubstr&keywords=PatchAvailable&keywords_type=anywords&field0-0-0=noop&type0-0-0=noop&value0-0-0=&cmdtype=doit&newqueryname=&order=Bug+Number">
+ Patch Available</a>
+ </li>
+ </ul>
+ </li>
+ <li>
+ <a href="http://issues.apache.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=LATER&resolution=REMIND&product=Struts&order=bugs.bug_id">
+ Reports to be handled "LATER"</a>
+ </li>
+ </ul>
+
+
+ </subsection>
+
+ <a name="Struts_1_x"/>
+ <subsection name="Struts Action Framework 1.x">
+
+ <p>
+ Through version 1.2.x, the project's codebase was bundled
+ as a single
+ distribution with a single release cycle.
+ Post version 1.2.x, the project's codebase is separated
+ into several
+ subprojects, each with its own distribution and release
+ cycle.
+ The core controller classes are now available as Struts
+ Action
+ Framework. The taglibs classes are now available as Struts
+ Taglib,
+ and so forth.
+ </p>
+
+ <p>
+ Popular third-party extensions that are in active use by
+ the Struts
+ community may be considered as new subprojects,
+ such as those distributed through the
+ <a href="http://sourceforge.net/projects/struts">
+ Struts SourceForge</a>
+ site.
+ (If you are the author of such an extension,
+ and would like to donate it to Apache Struts,
+ please contact the
+ <a href="http://struts.apache.org/mail.html">
+ Struts dev mailing list</a>
+ .)
+ </p>
+
+ <p>
+ Releases in the 1.x series will focus on refactoring of
+ existing functionality, with a continued emphasis on
+ backward
+ compatibility.
+ </p>
+ <p>
+ New features are being added to the 1.x series,
+ but only if backward compatability with the prior release
+ can be
+ retained.
+ The framework's API is evolving through a strict
+ deprecate/replace/remove protocol.
+ Developers are encouraged to stay current with the "best
+ available"
+ release and to observe deprecation warnings.
+ Features are deprecated before removal, and deprecated
+ features are
+ removed in a subsequent release.
+ </p>
+
+ <p>
+ Throughout the 1.x series,
+ there will be a continued emphasis on expanding unit test
+ coverage.
+ Bug reports should include a failing test case when
+ possible.
+ Proposals for new features should include a working test
+ suite.
+ (Creating features through Test Driven Development is
+ encouraged.)
+ </p>
+
+ <p>
+ Enhancement requests are logged in Bugzilla as they are
+ suggested.
+ <strong>The listing of an enhancement in Bugzilla does not
+ imply that
+ it is being "planned"</strong>
+ ,
+ merely that someone has suggested it,
+ and the idea hasn't been ruled out (yet).
+ </p>
+
+ <p>
+ Future release
+ <a href="milestones.html">milestones</a>
+ are provided
+ for enhancements which are being actively planned or
+ developed
+ but may not be ready for the current release.
+ If a report has not been tagged for a specific milestone
+ by a working developer,
+ then
+ <strong>it may never be implemented</strong>
+ .
+ When developers (including non-Committers) are actually
+ working on an
+ enhancement,
+ they should re-tag it for a specific release milestone,
+ such as "1.3.1" or "1.3.2".
+ </p>
+
+ <p>
+ If an enhancement has not been tagged for a specific
+ target,
+ feel free to start working on it yourself.
+ Many of our best features have been contributed by
+ developers,
+ just like you.
+ If you are working on an enhancement,
+ post a note on the ticket that you are working on an
+ enhancement
+ and then post a patch as soon as possible.
+ If the development effort doesn't succeed,
+ post a note to the ticket explaining what problem you had
+ creating the enhancement,
+ so that other developers can explore alternatives.
+ </p>
+
+ </subsection>
+
+ <a name="Struts_1_3_x"/>
+ <subsection name="Struts Action Framework 1.3.x and beyond">
+
+ <p>
+ An outline of the enhancements proposed here
+ can be found on the
+ <a href="milestones.html">Milestones</a>
+ page.
+ </p>
+
+ <p>
+ The 1.3.x series utilizes Struts Chain as the default
+ request
+ processor and adds an "extends" attribute to all the
+ configuration elements (a la Tiles).
+ We would also like to add a Ant-style properties file to
+ make
+ variable substitutions within the XML elements.
+ The substitution feature is supported by Spring and
+ iBATIS,
+ among others.
+ Substitutions are a useful way to configure applications
+ and reduce redundancy.
+ </p>
+
+ <p>
+ <b>Experimental Members</b>
+ </p>
+
+ <p>
+ To lay the groundwork for future changes,
+ three "experimental" classes and interfaces are being
+ added to
+ the framework so that early adopters can experiment with
+ using
+ Struts Chain to develop applications.
+ We do consider these members experimental,
+ and they are subject to change,
+ based on our experience using them with our own
+ applications.
+ </p>
+
+ <p>
+ <b>ActionCommand</b>
+ - A Chain Command-like interface with one
+ method:
+ </p>
+
+ <p>
+ <code>void execute(ActionContext context)</code>
+ </p>
+
+ <p>
+ Support for conventional Actions would stay in place,
+ but as an alternative,
+ a class could implement ActionCommand and unbind itself
+ from the HTTP API.
+ </p>
+
+ <p>
+ <b>ActionContext</b>
+ - A
+ <i>Chain Context</i>
+ that implements the
+ logical Action class API.
+ </p>
+
+ <p>
+ Existing code could be converted by changing references to
+ context.* and so forth.
+ The context could be constructed by the Request Processor,
+ as an optional Command in the Chain,
+ so that it could be exposed this through thread-local,
+ opening the door for POJO actions
+ that don't implement a particular interface.
+ </p>
+
+ <p>
+ <b>ViewContext</b>
+ - A
+ <i>Chain Context</i>
+ that implements the
+ logical "Velocity Tools" API.
+ </p>
+
+ <p>
+ In a later release, when the new members stabilize,
+ we could move the taglib dependencies from the servlet
+ contexts
+ to the ViewContext.
+ View technologies could then look exclusively to the
+ ViewContext
+ rather than poke around in the various servlet contexts.
+ (Of course,
+ support for the original architecture would remain for
+ some time,
+ to give third party libraries the chance to migrate.)
+ </p>
+
+ <p>
+ After having a chance to work with ActionContext and
+ ViewContext
+ ourselves,
+ we could introduce more support for these members in a
+ later
+ release.
+ But for 1.3.x, they could be marked "experimental".
+ </p>
+
+ <p>
+ The Commons Chain WebContext we now pass around Struts
+ Chain
+ could be called the "StrutsContext" to differentiate it
+ from the
+ ActionContext and ViewContext.
+ </p>
+
+ <p>
+ (Are we now starting to call everything "Context" instead
+ of
+ "Action"?
+ Not really.
+ We use the "Context" suffix when a member extends Chain
+ Context.
+ This convention is unlike the current "Action" soup,
+ since "Context" is a suffix that identifies a member's
+ "family" history.)
+ </p>
+ </subsection>
+
+ <a name="Struts_1_4_x"/>
+ <subsection name="Struts Action Framework 1.4.x considerations">
+
+ <p>
+ One we get past 1.3.x,
+ there are some other things that we might consider.
+ </p>
+
+ <p>
+ <b>Consider combining DTDs.</b>
+ Right now,
+ using "standard" extensions like Tiles and Validator mean
+ using
+ more than one configuration file.
+ While using multiple configurations files can be a good
+ thing,
+ we should also try and support the idea of having a single
+ configuration file.
+ This might not work-out for Tiles,
+ but we might be able to at least integrate the Validator
+ configuration with the DynaForm configuration.
+ </p>
+
+ <p>
+ <b>Consider adding catalog element.</b>
+ Depending on how the work goes with the experimental
+ ActionCommand interface,
+ we might identifiy a need to add a catalog element to the
+ configuration,
+ to support using a Chain of ActionCommands.
+ </p>
+
+ <p>
+ <b>Consider refactoring for Spring.</b>
+ We identified the need for adding a IOC container to
+ Struts
+ some time ago,
+ but stalled on the point of which to use.
+ Since then,
+ Spring has gained a lot of momentum.
+ Spring is used by the MyFaces and Beehive teams,
+ and its on the radar for Shale.
+ There is already a Struts-Spring component in the Spring
+ distribution and other common ground.
+ </p>
+ </subsection>
+
+ <a name="Struts_1_5_x"/>
+ <subsection name="Struts Action Framework 1.5.x considerations">
+
+ <p>
+ Based on our own work with the "experimental" members
+ introduced in 1.3.x,
+ we might consider some other changes.
+ </p>
+
+ <p>
+ <b>Consider a "smart" action type.</b>
+ The idea is that a command in Struts chain could look at
+ the type
+ indicated by the ActionMapping so both Action classes and
+ ActionCommand implementations are supported.
+ People could then mix-and-match Actions with
+ ActionCommands
+ (or even chains of ActionCommands).
+ We might even try placing an ActionCommand interface on
+ ActionForm,
+ so people could skip having a seperate Action or
+ ActionCommand
+ class.
+ The ActionForm could do it all.
+ </p>
+
+ <p>
+ <b>Consider a "populate" method on ActionForm.</b>
+ From an OOP standpoint,
+ it might be cleaner if an ActionForm populated itself
+ rather than
+ rely on a "god" class to populate it from the outside.
+ </p>
+
+ <p>
+ <b>Consider a "FormContext" mechanism.</b>
+ Rather than "throw-away" a request-based ActionForm,
+ the object could be seralized as a hidden-field or
+ session-object
+ and restored on the next request.
+ Many other frameworks support this behavior now.
+ Struts would have a slightly different spin,
+ since we look at the form as an named entity rather than
+ as an
+ anonymous aggregation of other objects.
+ </p>
+
+ </subsection>
+
+ <a name="Struts_1_6_x"/>
+ <subsection name="Struts Action Framework 1.6.x considerations">
+
+ <p>
+ <b>Consider multiple controllers.</b>
+ One reason we introduced modules was because "there can
+ only be
+ one" Struts controller in an application.
+ With the context-based changes we making,
+ we might be able to introduce a mechanism to support a
+ collection
+ of Struts controllers,
+ each identified by its servlet or filter name,
+ each with it's own URI pattern.
+ The key to being able to do something like this is for
+ view
+ members to look to the ViewContext rather than the various
+ servlet
+ contexts.
+ Each Struts controller would place the appropriate
+ ViewContext in
+ its own requests.
+ </p>
+
+ <p>
+ <b>Consider an alternate configuration file.</b>
+ There are idiosyncrasies in the element/attribute names of
+ the
+ struts-config which often confuse new developers.
+ By either supporting alternative configuration loaders,
+ or applying a stylesheet to a XML configuration,
+ we could support both the "classic" and a new
+ configuration
+ (based on something like
+ <a href="http://wiki.apache.org/struts/StrutsJericho">
+ Struts Jericho</a>
+ ).
+ </p>
+ </subsection>
+
+ <a name="Portlets"/>
+ <subsection name="Portlet (JSR-168) Whiteboard">
+ <p>
+ There are three major issues with supporting JSR-168
+ (and probably a bunch of smaller ones as well):
+ </p>
+
+ <ul>
+
+ <li>
+ The framrwork APIs assume servlet API objects
+ (ServletContext,
+ ServletRequest, ServletResponse), whereas JSR-168
+ talks about
+ PortletContext, PortletRequest, and PortletResponse.
+ We'd either need to change the calling sequence for
+ Action.execute() -- problematic for backwards
+ compatibility --
+ or fake it somehow in a portlet environment.
+ </li>
+
+ <li>
+ The lifecycle of a portlet request is actually divided
+ into two
+ chunks -- processing and then rendering.
+ From a Struts perspective,
+ that means making sure that the first part of the
+ request
+ processor pipeline need to happen in the "process"
+ part,
+ and the forwarding to the resulting page needs to
+ happen in the
+ "render" part.
+ </li>
+
+ <li>
+ Today,
+ Struts owns the process of calculating URLs for pages
+ and actions.
+ Because it's in a webapp,
+ it knows exactly what to do for the developer.
+ However,
+ in a portlet container it's actually the portal server
+ that
+ manages URLs,
+ so a Struts-based portlet would need to interact with
+ the portlet
+ APIs for this purpose.
+ </li>
+
</ul>
- </li>
- <li><a href="http://issues.apache.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&product=Struts&bug_severity=Enhancement&order=Bug+Number">Open enhancement reports</a>
+
+ <p>
+ A strong goal should be that an application should be
+ usable either as a webapp or as a portlet,
+ with little (ideally no) changes.
+ Therefore, we should build whatever it takes to support
+ this into
+ the standard framework distribution,
+ which could then be used in both environments.
+ </p>
+
+ </subsection>
+
+ <a name="Proposals"/>
+ <subsection name="Relevant Proposals">
+
<ul>
- <li><a href="http://issues.apache.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=Enhancement&email1=&emailtype1=substring&emailassigned_to1=1&email2=&emailtype2=substring&emailreporter2=1&bugidtype=include&bug_id=&changedin=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&product=Struts&short_desc=&short_desc_type=allwordssubstr&long_desc=&long_desc_type=allwordssubstr&bug_file_loc=&bug_file_loc_type=allwordssubstr&keywords=PatchAvailable&keywords_type=anywords&field0-0-0=noop&type0-0-0=noop&value0-0-0=&cmdtype=doit&newqueryname=&order=Bug+Number">Patch Available</a></li>
+ <li>
+ <a href="http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/chain/">
+ Commons Chain of Responsiblity package</a>
+ </li>
+
+ <li>
+ <a href="http://cvs.apache.org/viewcvs/jakarta-struts/contrib/struts-chain/">
+ Struts Chain Request Processor</a>
+ </li>
+
+ <li>
+ <a href="http://wiki.apache.org/struts/StrutsClassicRelease130">
+ Struts Classic Release Plan 1.3.0</a>
+ </li>
+
+ <li>
+ <a href="proposals/struts-faces.html">struts-faces
+ taglib</a>
+ </li>
+
+ <li>
+ <a href="http://wiki.apache.org/struts/StrutsJericho">
+ Struts Jericho</a>
+ </li>
+
+ <li>
+ <a href="http://wiki.apache.org/struts/StrutsShale">
+ Struts Shale</a>
+ </li>
+
+ <li>
+ <a href="http://wiki.apache.org/struts/StrutsTi">
+ Struts Ti</a>
+ </li>
+
+ <li>
+ <a href="http://wiki.apache.org/struts/StrutsOverDrive">
+ Struts OverDrive</a>
+ </li>
+
</ul>
- </li>
- <li><a href="http://issues.apache.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=LATER&resolution=REMIND&product=Struts&order=bugs.bug_id">Reports to be handled "LATER"</a></li>
- </ul>
-
-
- </subsection>
-
-<a name="Struts_1_x"/>
-<subsection name="Struts Action Framework 1.x">
-
- <p>
- Through version 1.2.x, the project's codebase was bundled as a single
- distribution with a single release cycle.
- Post version 1.2.x, the project's codebase is separated into several
- subprojects, each with its own distribution and release cycle.
- The core controller classes are now available as Struts Action
- Framework. The taglibs classes are now available as Struts Taglib,
- and so forth.
- </p>
-
- <p>
- Popular third-party extensions that are in active use by the Struts
- community may be considered as new subprojects,
- such as those distributed through the
- <a href="http://sourceforge.net/projects/struts">
- Struts SourceForge</a> site.
- (If you are the author of such an extension,
- and would like to donate it to Apache Struts,
- please contact the <a href="http://struts.apache.org/mail.html">
- Struts dev mailing list</a>.)
- </p>
-
- <p>
- Releases in the 1.x series will focus on refactoring of
- existing functionality, with a continued emphasis on backward
- compatibility.
- </p>
- <p>
- New features are being added to the 1.x series,
- but only if backward compatability with the prior release can be
- retained.
- The framework's API is evolving through a strict
- deprecate/replace/remove protocol.
- Developers are encouraged to stay current with the "best available"
- release and to observe deprecation warnings.
- Features are deprecated before removal, and deprecated features are
- removed in a subsequent release.
- </p>
-
- <p>
- Throughout the 1.x series,
- there will be a continued emphasis on expanding unit test coverage.
- Bug reports should include a failing test case when possible.
- Proposals for new features should include a working test suite.
- (Creating features through Test Driven Development is encouraged.)
- </p>
-
- <p>
- Enhancement requests are logged in Bugzilla as they are suggested.
- <strong>The listing of an enhancement in Bugzilla does not imply that
- it is being "planned"</strong>,
- merely that someone has suggested it,
- and the idea hasn't been ruled out (yet).
- </p>
-
- <p>
- Future release <a href="milestones.html">milestones</a> are provided
- for enhancements which are being actively planned or developed
- but may not be ready for the current release.
- If a report has not been tagged for a specific milestone
- by a working developer,
- then <strong>it may never be implemented</strong>.
- When developers (including non-Committers) are actually working on an
- enhancement,
- they should re-tag it for a specific release milestone,
- such as "1.3.1" or "1.3.2".
- </p>
-
- <p>
- If an enhancement has not been tagged for a specific target,
- feel free to start working on it yourself.
- Many of our best features have been contributed by developers,
- just like you.
- If you are working on an enhancement,
- post a note on the ticket that you are working on an enhancement
- and then post a patch as soon as possible.
- If the development effort doesn't succeed,
- post a note to the ticket explaining what problem you had
- creating the enhancement,
- so that other developers can explore alternatives.
- </p>
-
- </subsection>
-
- <a name="Struts_1_3_x"/>
- <subsection name="Struts Action Framework 1.3.x and beyond">
-
- <p>
- An outline of the enhancements proposed here
- can be found on the
- <a href="milestones.html">Milestones</a> page.
- </p>
-
- <p>
- The 1.3.x series utilizes Struts Chain as the default request
- processor and adds an "extends" attribute to all the
- configuration elements (a la Tiles).
- We would also like to add a Ant-style properties file to make
- variable substitutions within the XML elements.
- The substitution feature is supported by Spring and iBATIS,
- among others.
- Substitutions are a useful way to configure applications
- and reduce redundancy.
- </p>
-
- <p>
- <b>Experimental Members</b>
- </p>
-
- <p>
- To lay the groundwork for future changes,
- three "experimental" classes and interfaces are being added to
- the framework so that early adopters can experiment with using
- Struts Chain to develop applications.
- We do consider these members experimental,
- and they are subject to change,
- based on our experience using them with our own applications.
- </p>
-
- <p>
- <b>ActionCommand</b> - A Chain Command-like interface with one
- method:
- </p>
-
- <p><code>void execute(ActionContext context)</code></p>
-
- <p>
- Support for conventional Actions would stay in place,
- but as an alternative,
- a class could implement ActionCommand and unbind itself
- from the HTTP API.
- </p>
-
- <p>
- <b>ActionContext</b> - A <i>Chain Context</i> that implements the
- logical Action class API.
- </p>
-
- <p>
- Existing code could be converted by changing references to
- context.* and so forth.
- The context could be constructed by the Request Processor,
- as an optional Command in the Chain,
- so that it could be exposed this through thread-local,
- opening the door for POJO actions
- that don't implement a particular interface.
- </p>
-
- <p>
- <b>ViewContext</b> - A <i>Chain Context</i> that implements the
- logical "Velocity Tools" API.
- </p>
-
- <p>
- In a later release, when the new members stabilize,
- we could move the taglib dependencies from the servlet contexts
- to the ViewContext.
- View technologies could then look exclusively to the ViewContext
- rather than poke around in the various servlet contexts.
- (Of course,
- support for the original architecture would remain for some time,
- to give third party libraries the chance to migrate.)
- </p>
-
- <p>
- After having a chance to work with ActionContext and ViewContext
- ourselves,
- we could introduce more support for these members in a later
- release.
- But for 1.3.x, they could be marked "experimental".
- </p>
-
- <p>
- The Commons Chain WebContext we now pass around Struts Chain
- could be called the "StrutsContext" to differentiate it from the
- ActionContext and ViewContext.
- </p>
-
- <p>
- (Are we now starting to call everything "Context" instead of
- "Action"?
- Not really.
- We use the "Context" suffix when a member extends Chain Context.
- This convention is unlike the current "Action" soup,
- since "Context" is a suffix that identifies a member's
- "family" history.)
- </p>
- </subsection>
-
- <a name="Struts_1_4_x"/>
- <subsection name="Struts Action Framework 1.4.x considerations">
-
- <p>
- One we get past 1.3.x,
- there are some other things that we might consider.
- </p>
-
- <p>
- <b>Consider combining DTDs.</b>
- Right now,
- using "standard" extensions like Tiles and Validator mean using
- more than one configuration file.
- While using multiple configurations files can be a good thing,
- we should also try and support the idea of having a single
- configuration file.
- This might not work-out for Tiles,
- but we might be able to at least integrate the Validator
- configuration with the DynaForm configuration.
- </p>
-
- <p>
- <b>Consider adding catalog element.</b>
- Depending on how the work goes with the experimental
- ActionCommand interface,
- we might identifiy a need to add a catalog element to the
- configuration,
- to support using a Chain of ActionCommands.
- </p>
-
- <p>
- <b>Consider refactoring for Spring.</b>
- We identified the need for adding a IOC container to Struts
- some time ago,
- but stalled on the point of which to use.
- Since then,
- Spring has gained a lot of momentum.
- Spring is used by the MyFaces and Beehive teams,
- and its on the radar for Shale.
- There is already a Struts-Spring component in the Spring
- distribution and other common ground.
- </p>
- </subsection>
-
- <a name="Struts_1_5_x"/>
- <subsection name="Struts Action Framework 1.5.x considerations">
-
- <p>
- Based on our own work with the "experimental" members
- introduced in 1.3.x,
- we might consider some other changes.
- </p>
-
- <p>
- <b>Consider a "smart" action type.</b>
- The idea is that a command in Struts chain could look at the type
- indicated by the ActionMapping so both Action classes and
- ActionCommand implementations are supported.
- People could then mix-and-match Actions with ActionCommands
- (or even chains of ActionCommands).
- We might even try placing an ActionCommand interface on
- ActionForm,
- so people could skip having a seperate Action or ActionCommand
- class.
- The ActionForm could do it all.
- </p>
-
- <p>
- <b>Consider a "populate" method on ActionForm.</b>
- From an OOP standpoint,
- it might be cleaner if an ActionForm populated itself rather than
- rely on a "god" class to populate it from the outside.
- </p>
-
- <p>
- <b>Consider a "FormContext" mechanism.</b>
- Rather than "throw-away" a request-based ActionForm,
- the object could be seralized as a hidden-field or session-object
- and restored on the next request.
- Many other frameworks support this behavior now.
- Struts would have a slightly different spin,
- since we look at the form as an named entity rather than as an
- anonymous aggregation of other objects.
- </p>
-
- </subsection>
-
- <a name="Struts_1_6_x"/>
- <subsection name="Struts Action Framework 1.6.x considerations">
-
- <p>
- <b>Consider multiple controllers.</b>
- One reason we introduced modules was because "there can only be
- one" Struts controller in an application.
- With the context-based changes we making,
- we might be able to introduce a mechanism to support a collection
- of Struts controllers,
- each identified by its servlet or filter name,
- each with it's own URI pattern.
- The key to being able to do something like this is for view
- members to look to the ViewContext rather than the various servlet
- contexts.
- Each Struts controller would place the appropriate ViewContext in
- its own requests.
- </p>
-
- <p>
- <b>Consider an alternate configuration file.</b>
- There are idiosyncrasies in the element/attribute names of the
- struts-config which often confuse new developers.
- By either supporting alternative configuration loaders,
- or applying a stylesheet to a XML configuration,
- we could support both the "classic" and a new configuration
- (based on something like
- <a href="http://wiki.apache.org/struts/StrutsJericho">
- Struts Jericho</a>).
- </p>
- </subsection>
-
-<a name="Portlets"/>
-<subsection name="Portlet (JSR-168) Whiteboard">
- <p>
- There are three major issues with supporting JSR-168
- (and probably a bunch of smaller ones as well):
- </p>
-
- <ul>
-
- <li>
- The framrwork APIs assume servlet API objects (ServletContext,
- ServletRequest, ServletResponse), whereas JSR-168 talks about
- PortletContext, PortletRequest, and PortletResponse.
- We'd either need to change the calling sequence for
- Action.execute() -- problematic for backwards compatibility --
- or fake it somehow in a portlet environment.
- </li>
-
- <li>
- The lifecycle of a portlet request is actually divided into two
- chunks -- processing and then rendering.
- From a Struts perspective,
- that means making sure that the first part of the request
- processor pipeline need to happen in the "process" part,
- and the forwarding to the resulting page needs to happen in the
- "render" part.
- </li>
-
- <li>
- Today,
- Struts owns the process of calculating URLs for pages and actions.
- Because it's in a webapp,
- it knows exactly what to do for the developer.
- However,
- in a portlet container it's actually the portal server that
- manages URLs,
- so a Struts-based portlet would need to interact with the portlet
- APIs for this purpose.
- </li>
-
- </ul>
-
- <p>
- A strong goal should be that an application should be
- usable either as a webapp or as a portlet,
- with little (ideally no) changes.
- Therefore, we should build whatever it takes to support this into
- the standard framework distribution,
- which could then be used in both environments.
- </p>
-
-</subsection>
-
-<a name="Proposals"/>
-<subsection name="Relevant Proposals">
-
- <ul>
- <li>
- <a href="http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/chain/">
- Commons Chain of Responsiblity package</a>
- </li>
-
- <li>
- <a href="http://cvs.apache.org/viewcvs/jakarta-struts/contrib/struts-chain/">
- Struts Chain Request Processor</a>
- </li>
-
- <li>
- <a href="http://wiki.apache.org/struts/StrutsClassicRelease130">
- Struts Classic Release Plan 1.3.0</a>
- </li>
-
- <li>
- <a href="proposals/struts-faces.html">struts-faces taglib</a>
- </li>
-
- <li>
- <a href="http://wiki.apache.org/struts/StrutsJericho">
- Struts Jericho</a>
- </li>
-
- <li>
- <a href="http://wiki.apache.org/struts/StrutsShale">
- Struts Shale</a>
- </li>
-
- <li>
- <a href="http://wiki.apache.org/struts/StrutsTi">
- Struts Ti</a>
- </li>
-
- <li>
- <a href="http://wiki.apache.org/struts/StrutsOverDrive">
- Struts OverDrive</a>
- </li>
-
- </ul>
-
-</subsection>
-
-</section>
-
-<section>
- <p class="right">Next:
- <a href="userGuide/index.html">User Guide</a></p>
-</section>
-</body></document>
+ </subsection>
+
+ </section>
+
+ <section>
+ <p class="right">Next:
+ <a href="userGuide/index.html">User Guide</a>
+ </p>
+ </section>
+
+ </body>
+</document>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org