struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig McClanahan <craig...@gmail.com>
Subject Re: Spring and XWork in Ti
Date Thu, 01 Sep 2005 18:29:31 GMT
On 9/1/05, Don Brown <mrdon@twdata.org> wrote:

Therefore, my point is an interceptor chain is better suited to a scalable,
> linear process flow, while chain is better for decision points. And 
> neither,
> I'd argue, is well suited for a robust, configurable workflow, and this 
> surely
> we can agree we are seeing with commons-chain in Struts Classic.


I generally agree with this, and the other points Don has made in this 
thread ... and would suggest (sorry Don :-) that the same issue happens with 
continuations based architectures like Cocoon Webflow and Struts Flow. None 
of these approaches seem to deal with conditional branches in workflows very 
well.

This is one of the reasons that I was initially enamored with Spring 
WebFlow's approach, which defines the processing logic as a series of 
states, linked by transitions. States can be action states (like calling 
Action.execute() in a Struts app) or view states (display a page, receive 
the subsequent form submit. All states return an outcome that can be used to 
drive the transition, so you can do branches very easily. Or, you can glue 
together any number of action states in sequence to get the fine grained 
sequential functionality that a chain provides.

In Shale, this idea is encapsulated as a "dialog", which leverages the fact 
that JSF action methods already returned a String outcome (so that it fit 
naturally into the state transition model) -- I just added the idea of an 
action state represented as an expression that called some arbitrary method 
that also returned a String. This lets you do things like representing an 
entire workflow in an easy to understand configuration (or, equivalently, in 
a UML state diagram):

<!-- Log On / Create Profile Dialog -->
<dialog name="Log On"
start="Check Cookie">

<action name="Check Cookie"
method="#{profile$logon.check}">
<transition outcome="authenticated"
target="Exit"/>
<transition outcome="unauthenticated"
target="Logon Form"/>
</action>

<view name="Logon Form"
viewId="/profile/logon.jsp">
<transition outcome="authenticated"
target="Exit"/>
<transition outcome="create"
target="Create Profile"/>
</view>

<subdialog name="Create Profile"
dialogName="Edit Profile">
<transition outcome="success"
target="Exit"/>
</subdialog>

<end name="Exit"
viewId="/usecases.jsp"/>

</dialog>

Although the dialog facility is primary focused around multi-request 
workflows, you can leverage the same concepts for fine grained flows within 
a particular request.

Craig



Don
> 
> BTW, I'm really enjoying this discussion and have missed these on this 
> list.
> 
> Ted Husted wrote:
> > On 9/1/05, Don Brown <mrdon@twdata.org> wrote:
> >
> >>In that case, I find interceptors more practical, as they allow
> >>you to have code before and after processing that uses method variables. 
> With
> >>Chain, you have to use a Filter and even then, there is no way to share
> >>variables between the two blocks of code without instance variables 
> which has
> >>its own problems.
> >
> >
> > First, you're doing the work, Don, and so you're welcome to make the
> > decisions :)
> >
> > Though, I don't understand is why you'd want to be restricted to two
> > blocks of code :)
> >
> > With Chain, any number of blocks of code, be they commands or chains,
> > in any combination, can be the object of the request processing.
> >
> > In OverDrive/Nexus, we do find having interceptors that surround each
> > request useful. It's not hard to define "pre" and "post" chains, and
> > then at runtime create a third chain to execute them all.
> >
> > public void ExecuteView (IRequestContext context)
> > {
> > IRequestCommand command = VerifyRequest (context);
> > if (context.IsNominal)
> > {
> > IChain chain = new Chain ();
> > if (_PreOp!=null) chain.AddCommand (_PreOp);
> > chain.AddCommand (command);
> > if (_PostOp!=null) chain.AddCommand (_PostOp);
> > try
> > {
> > chain.Execute (context);
> > }
> > catch (Exception e)
> > {
> > context.Fault = e;
> > }
> > }
> > }
> >
> > 
> http://svn.apache.org/viewcvs.cgi/struts/sandbox/trunk/overdrive/Nexus/Extras/Spring/Catalog.cs?view=markup
> >
> > The PreOp and PostOp chains are defined in the configuration, along
> > with everything else.
> >
> > But, we're not trying to solve the problems of navigational workflows,
> > only the problem of processing business use cases and interacting with
> > a presentation layer
> >
> > -Ted.,
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
> 
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message