Roman, Taavi,
I agree with your assessment re: problems with the example I gave earlier:
it fails to allow the String returned by go() to determine the flow for the
first controllers.
Consider this alternative. Note that this is fleshed out a bit more than the
original maverick.xml I started with as Taavi wants to see the
authentication stuff illustrated more thoroughly.
<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>
This approach gives us nearly as simple and readable as the former, but it
supports simple flow control the previous example fatally lacked. If go()
returns the value of the proceedOn attribute we execute the next controller,
otherwise it renders a view listed within the <controller> tag or outside of
the <controller-pipeline> tag.
Consider how easily we may trace the execution of myCommand1 in comparison
to the following maverick.xml. Notice especially how each solution scales.
With the above, we just add another section for each command, below we add
two commands to handle for every one we want to deal with, additionally we
must add views to the authentication authenticationCheck & moduleSpecific1
commands. Also notice how additional complexity (having some pages calling
secure vs. insecure controllers, for instance) makes the maverick.xml below
even more difficult to follow, where it would be fairly straight forward
above.
<!-- command 1 -->
<command name="myCommand1">
<controller class="com.foo.Bootstrap"/>
<view name="continue" path="authenticationCheck.m"/>
<view name="error" path="fatalErrorPage.jsp"/>
</command>
<command name="continueCommand1">
<controller class="com.foo.Command1"/>
<view name="success" path="myPage.jsp"/>
<view name="error" path="errorPage.jsp"/>
</command>
<!-- utility controllers do not call directly! -->
<command name="authenticationCheck">
<controller class="com.foo.AuthenticationCheck"/>
<view name="continueModule1" path="moduleSpecific1.m"/>
<view name="continueModule2" path="moduleSpecific2.m"/>
<view name="displayLogin" path="login.jsp"/>
<view name="notAuthorized" path="notAuthorized.jsp"/>
</command>
<command name="moduleSpecific1">
<controller class="com.foo.ModuleSpecific1"/>
<view name="continue_command1" path="continueCommand1.m"/>
<view name="continue_command2" path="continueCommand2.m"/>
</command>
Obviously, if we just use inheritance to combine all controllers into a
single object, the messy configuration files go away. I am only proposing
this because there are situations where doing so would be mistake because of
the complexity involved. Inheritance is powerful, but it can be
overused--and it can have a negative rather than positive impact on reuse,
particularly in Java in which a class can extend only one superclass. At
least in the application I am working on, the shared functionality is mixed
and matched in various controllers in such a way that I need to be able to
build up controllers with something more akin to composition, rather than
inheritance. As others have already pointed out, I believe chaining
controllers is just the ticket. At this point I am trying to discover, with
input from others, how to best facilitate such an approach in manner that is
as simple and flexible as possible.
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: Scholarships for Techies!
Can't afford IT training? All 2003 ictp students receive scholarships.
Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more.
www.ictp.com/training/sourceforge.asp
[INVALID FOOTER]
