For those that are following this project, I have made a few changes to the
proposal for the new pipeline element. Consider the following example from a
previous email:
--------------------------------------------------------
<command name="myCommand1">
<controller-pipeline>
<controller class="com.foo.Bootstrap" proceedOn="continue">
<view name="error" path="fatalErrorPage.jsp"/>
</controller>
<controller class="com.foo.Authenticate" proceedOn="continue">
<view name="displayLogin" path="login.jsp"/>
<view name="notAuthorized" path="notAuthorized.jsp"/>
</controller>
<controller class="com.foo.ModuleSpecific1" proceedOn="continue"/>
<controller class="com.foo.Command1"/>
</controller-pipeline>
<view name="success" path="myPage.jsp"/>
<view name="error" path="errorPage.jsp"/>
</command>
--------------------------------------------------------
At the expense of a little clarity, the following is considerably more
flexible and it does not litter the controller with sub-elements thereby
persevering the ability of existing controllers to make use of sub-elements
for their own configuration data.
--------------------------------------------------------
<command name="myCommand1">
<controller-pipeline>
<!-- bootstrap -->
<controller name="bootstrap" class="com.foo.Bootstrap"/>
<connector src="bootstrap" target="auth" event="continue"/>
<connector src="bootstrap target="fatalError" type="view"
event="error"/>
<!-- auth -->
<controller name="auth" class="com.foo.Authenticate"/>
<connector src="auth" target="foo" event="continue"/>
<!-- foo -->
<controller name="foo" class="com.foo.ModuleSpecific1"/>
<connector src="foo" target="bar" event="continue"/>
<!-- bar -->
<controller name="bar" class="com.foo.Command1"/>
</controller-pipeline>
<view name="fatalError" path="fatalErrorPage.jsp"/>
<view name="notAuthorized" path="notAuthorized.jsp"/>
<view name="displayLogin" path="login.jsp"/>
<view name="success" path="myPage.jsp"/>
<view name="error" path="errorPage.jsp"/>
</command>
--------------------------------------------------------
Here we use connector elements rather than nested elements to indicate flow.
The "event" attribute of the connector matches the String returned by the
"source" controller, the "target" names the controller or view to call. The
"type" attribute allows us to have separate namespaces for controllers and
views; it defaults to 'controller' and is only necessary when referring to a
view.
Notice that connectors are not necessary to connect a controller to a view
except when the String returned by the controller does not name the desired
view. The connector can then be used to contextualize or override the view
called. For example, the bootstrap controller returns the String "error" but
we'd rather call the "fatalError" view than the "error" view so we simply
use a connector. This allows us to make routing changes via maverick.xml
without having to make code changes in the controller. The return value for
controllers can become an interface of sorts with the implementation left to
maverick.xml.
John-Mason Shackelford
Software Developer
NCS Pearson - Measurement Services
2510 North Dodge St.
Iowa City, IA 52245
319-354-9200x6214
[EMAIL PROTECTED]
****************************************************************************
This email may contain confidential material.
If you were not an intended recipient,
Please notify the sender and delete all copies.
We may monitor email to and from our network.
****************************************************************************
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
[INVALID FOOTER]
