Mailing-List: contact dev-help@struts.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Struts Developers List" <dev@struts.apache.org>
Received-SPF: pass (asf.osuosl.org: domain of craigmcc@gmail.com designates
 64.233.170.203 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:references;
        b=lHHk/navHtSBu3wG21EcN/LQzWjsvchfhPK2/x5Q5wOzsk9DfS26zhluS/6xpdLWDE8GAugjwRdXkEMDXJUPsfUhOn0qKEk8hEZnOnV1+tSwf+HcmxM1wNgBvGH8GO2bJtdVw0m1/x0NewJotEsR5WgJ48Gg5fPhFuHgZEL7XaE=
Message-ID: <f8b39ace050901112953cb97c0@mail.gmail.com>
Date: Thu, 1 Sep 2005 11:29:31 -0700
From: Craig McClanahan <craigmcc@gmail.com>
Reply-To: craigmcc@apache.org
To: Struts Developers List <dev@struts.apache.org>
Subject: Re: Spring and XWork in Ti
In-Reply-To: <4317431C.6000307@twdata.org>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_2000_32438312.1125599371695"
References: <dev112$1vp$1@sea.gmane.org> <a06210204bf3bb03e47c9@192.168.2.102>
	 <a06210205bf3bbc9f2eaf@192.168.2.102> <4316144F.6060300@twdata.org>
	 <8b3ce37905090105531d42e676@mail.gmail.com>
	 <43171DA3.8040105@twdata.org> <a06210209bf3cda7fc7e9@129.105.128.223>
	 <43173396.5060807@twdata.org>
	 <8b3ce379050901104616436885@mail.gmail.com>
	 <4317431C.6000307@twdata.org>

------=_Part_2000_32438312.1125599371695
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

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=20
> neither,
> I'd argue, is well suited for a robust, configurable workflow, and this=
=20
> 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=20
thread ... and would suggest (sorry Don :-) that the same issue happens wit=
h=20
continuations based architectures like Cocoon Webflow and Struts Flow. None=
=20
of these approaches seem to deal with conditional branches in workflows ver=
y=20
well.

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

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

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

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

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

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

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

</dialog>

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

Craig


Don
>=20
> BTW, I'm really enjoying this discussion and have missed these on this=20
> list.
>=20
> 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=
.=20
> 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=20
> 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 =3D VerifyRequest (context);
> > if (context.IsNominal)
> > {
> > IChain chain =3D new Chain ();
> > if (_PreOp!=3Dnull) chain.AddCommand (_PreOp);
> > chain.AddCommand (command);
> > if (_PostOp!=3Dnull) chain.AddCommand (_PostOp);
> > try
> > {
> > chain.Execute (context);
> > }
> > catch (Exception e)
> > {
> > context.Fault =3D e;
> > }
> > }
> > }
> >
> >=20
> http://svn.apache.org/viewcvs.cgi/struts/sandbox/trunk/overdrive/Nexus/Ex=
tras/Spring/Catalog.cs?view=3Dmarkup
> >
> > 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
> >
>=20
>=20
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>=20
>

------=_Part_2000_32438312.1125599371695--