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 2004/12/23 04:03:31 UTC
svn commit: r123162 - /struts/core/trunk/doc/roadmap.xml
Author: husted
Date: Wed Dec 22 19:03:30 2004
New Revision: 123162
URL: http://svn.apache.org/viewcvs?view=rev&rev=123162
Log:
Add descriptions of proposed 1.3.x and beyond enhancements.
Modified:
struts/core/trunk/doc/roadmap.xml
Modified: struts/core/trunk/doc/roadmap.xml
Url: http://svn.apache.org/viewcvs/struts/core/trunk/doc/roadmap.xml?view=diff&rev=123162&p1=struts/core/trunk/doc/roadmap.xml&r1=123161&p2=struts/core/trunk/doc/roadmap.xml&r2=123162
==============================================================================
--- struts/core/trunk/doc/roadmap.xml (original)
+++ struts/core/trunk/doc/roadmap.xml Wed Dec 22 19:03:30 2004
@@ -127,12 +127,197 @@
so that other developers can explore alternatives.
</p>
- <p>
- More detail regarding Struts 1.x enhancements can be found on the
- <a href="Milestones.html">Milestones</a> page.
+ </section>
- </p>
+ <section href="Struts_1_3_x" name="Struts 1.3.x and beyond">
+
+ <p>
+ An outline of the Struts 1.x enhancements proposed here can be found on the
+ <a href="Milestones.html">Milestones</a> page.
+ </p>
+
+ <p>
+ As planned, in Struts 1.3.x we would integrate Struts Chain from config and add
+ an "extends" attribute to all the configruation elements (a la Tiles). While
+ we're at it, I'd also like to add a Ant-style properties file to make variable
+ substitutions within the XML elements. We use this in iBATIS, and it can be a
+ helpful way to configure applications and reduce redundancy.
+ </p>
+
+ <p>
+ <b>Experimental Members</b>
+ </p>
+
+ <p>
+ Those items by themselves seem like enough for a release, but we might add a
+ few "experimental" classes and interfaces to give us a chance to play with
+ Struts Chain in our own applications. We came up with two experimental classes
+ and an experimental interface: ActionCommand, ActionContext, and ViewContext.
+ </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, 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,
+ they could be marked "experimental".
+ </p>
+
+ <p>
+ The Commons Chaain 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>
+
+ <p><b>Subproject Distributions</b></p>
+ <p>
+ Also as planned, we would extract the Taglibs package into its own subproject.
+ (Giving us a chance to make the Taglibs 1.0.1 release utilize the ViewContext.)
+ We might also consider extracting "Actions" (plural) and "Plugins" into a
+ separate "Extras" subproject. While the members here are popular, they are
+ optional, and not essential to the core.
+ </p>
+
+ <p>
+ We've mentioned that each subproject should have its own release cycle. We've
+ also mentioned the idea of "bundling" subprojects into a master distribution.
+ We might consider taking that idea a step further and utilize the "Linux"
+ approach. The Struts "1.3.0" distribution could be an aggregation of "Core
+ 1.0.x", "Taglibs 1.0.x", and "Extras 1.0.x".
+ </p>
+
+ <p>
+ Later, if we end up with a Taglibs 1.0.1 GA before there is another Core 1.0.x
+ GA, we could assemble a "Struts 1.3.1" distribution that aggregates (for
+ example) "Core 1.0.0", "Taglibs 1.0.1", and "Extras 1.0.0".
+ </p>
+
+ <p>
+ The Struts aggregate distribution doesn't have to be complicated, perhaps just
+ a ZIP of whatever subproject GA distributions work with the "best available"
+ core.
+ </p>
+
+ <p><b>1.4 considerations</b></p>
+
+ <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 Struts 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>
+
+ <p><b>1.5 considerations</b></p>
+
+ <p>
+ Based on our own work with the "experimental" members inroduced 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 support placing an ActionCommand interface on ActionForm, so
+ people could skip having a sepate 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 an "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>
+
+ <p><b>1.6 considerations</b></p>
+
+ <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.
+ </p>
</section>
<section href="Struts_2_0" name="Struts 2.0.x">
@@ -274,12 +459,12 @@
</p>
<p>
As JSF comes into broader use, it is expected that
- Struts developers will continue to offer enhancements to make it even easier to use Struts with JSF.
+ Struts developers will continue to offer enhancements to make it even easier to use Struts with JSF,
+ such as the <a href="http://wiki.apache.org/struts/StrutsShale">Struts Shale</a> proposal.
</p>
<p>
- The SourceForge <a href="http://sf.net/projects/myfaces">MyFaces</a> team is in the process of
- joining the Apache Software Founcation. Once the Apache MyFaces team has access to the Apache TCK, it
+ The <a href="http://incubator.apache.org/myfaces/">MyFaces team</a> is in the process of joining the Apache Software Founcation. Once the Apache MyFaces team has access to the Apache TCK, it
is expected to be recognized as a certified JSF implementation.
</p>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org