<snip>
For the other usage, where people have trouble creating a finely-grained
business API, there's a new Chain package in the Commons sandbox that
can help. This package makes it easy to chain together arbitrary units
of work, so that you can do things like create a "move" command by
chaining a "copy" command to a "delete" command -- and still use "copy"
or "delete" on their own.
</snip>
Interesting. Sounds a lot like something I banged together the other day - a
thing I unimaginatevly called the "steplib" as its a library for configuring
steps to be executed.
Basically the units of work are classes that extend the Step class which
defines a begin() & end() method that one overrides. Steps are organised
into a tree, and can have children. If a steps begin() returns true the
children are executed, and if a steps end() (executed after children are
executed) returns true then the step is repeated. The step classes are
stateless in a similar manner to actions and servlets, etc... and are
configured in xml files which I read with digester the first time a
particluar sequence is requested, and reuse for all subsequent requests for
that sequence.
I did make a StepAction class that will execute a tree of steps (that
subclass ActionStep heheh) for an action, though actually that was an
afterthought and Im not using it much yet! The primary reason I built this
thing was for use as a view rendering technology (Im allergic to JSP and
prefer to decorate org.w3c.dom.Document trees (ahhh random access to my
xhtml. Oh joy :->)...) as I wanted a better way to configure a sequence of
more fine-grained DOM decorators.
Heres an example that does a listview table thingy:
<stamp id="stamp" mode="get" name="userRowStamp" remove="true">
<iterate exposeName="user" beanName="users" beanScope="request">
<log text="UserId:" name="user" property="userId" scope="request"/>
<stamp id="userTable" mode="put" name="userRowStamp" remove="false">
<populate id="userTable" name="user"/>
<rewrite id="userLink" forward="userEdit" paramId="userId"
paramName="user" property="userId"/>
<attribute id="userCheckbox" attribute="value" name="user"
property="userId"/>
<equals empty="true" name="user" property="roles">
<stamp id="roles_value" mode="get" remove="true"/>
</equals>
<equals not="true" empty="true" name="user" property="roles">
<stamp id="roles_br" mode="get" remove="true"/>
</equals>
<attribute id="stamp" attribute="id" remove="true" recurse="true"/>
</stamp>
</iterate>
</stamp>
Of course for an action step sequence the steps could do such things as
"copy" or "delete".
-----Original Message-----
From: Ted Husted [mailto:[EMAIL PROTECTED]
Sent: Saturday, 27 September 2003 10:16
To: Struts Developers List
Subject: Re: Action Chaining
It is becoming commonplace to use an Action as a "front" for a server
page. This is not what people mean when they talk about Action chaining.
Some people start to use the Actions as finely-grained business actions.
For example, they want to accomplish a "move" by forwarding to a
"copy" Action and then have the copy Action forward to a "delete"
Action. So the point of forwarding to the next Action not to complete
the response, as contemplated by the architecture, but to continue the
business transaction. In essence, they try to use Actions to create a
Chain of Responsibility. IMHO, that's out of scope for an Action class.
It is true that we ask too much of the Action class. In fact, we have
been discussing the idea of adding another "View" handler class, or a
"page controller", to the ActionForward. The idea being that the Action
might nest a call to this class (when specified) as part of the
FindForward sequence. The View class could then prepare the request for
whatever page it is designed to service.
Tying it to the FindForward sequence keeps the calls to the business
layer within the Action lifecycle, but allows for a separation of
concerns. The Action class can focus on the core business transaction,
and the View class can focus on preparing the request for its server
page -- once the core transaction is completed and the ActionForward is
ready to be selected.
http://www.mail-archive.com/[EMAIL PROTECTED]/msg18629.html
It's just a matter of some interested party coming up with an
implementation for other people to try.
For the other usage, where people have trouble creating a finely-grained
business API, there's a new Chain package in the Commons sandbox that
can help. This package makes it easy to chain together arbitrary units
of work, so that you can do things like create a "move" command by
chaining a "copy" command to a "delete" command -- and still use "copy"
or "delete" on their own.
-Ted.
Derek Richardson wrote:
> I was trying to avoid rehashing old arguments about action chaining. I
have heard two arguments: one, it is not supported and can cause strange
results and, two, it is indicative of bad design (the argument made below).
>
> I disagree that action chaining is always indicative of bad design. See my
email on the users list (that got no discussion, which I never understood)
http://marc.theaimsgroup.com/?l=struts-user&m=104370639426791&w=2. I believe
I made an original argument for action chaining being almost required in a
particular situation.
>
> In any case, I am not trying to force the committers to make action
chaining easier in the vanilla struts distribution. I was merely hoping to
get feedback if there is an obvious problem with my approach.
>
> Perhaps I should have posted to the users list - I thought that, since
this deals with modifying the framework instead of just implementing within
it, that I'd get better feedback here.
>
> Thanks,
>
> Derek Richardson
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
