struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From AKostylev <>
Subject Re[2]: Again Action Chaining
Date Thu, 18 Mar 2004 14:14:37 GMT
Здравствуйте Ted,

Thursday, March 18, 2004, 4:45:01 PM, you wrote:

TH> On Thu, 18 Mar 2004 15:24:25 +0300, AKostylev wrote:
>> How can I avoid action chaining in such situation... In my
>> application user can set "resolution" on some "demand". For
>> example, there two types of resolutions: "bug" and "not a bug". If
>> user selects "not a bug" option on form, then nothing happens...
>> But if user selects "bug" option, then he must create object "bug".
>> But also user can create object "bug" from another place of
>> application. So I get two actions: ResolutionSelectAction and
>> BugCreateAction, how can avoid action chaining between them and
>> move this dependence to business logic?

TH> The Actions should not be implementing the business logic.
TH> The business logic should be behind a facade where any Action can
TH> call it. In this way, if multiple Actions need to call an
TH> operation, like "createBug", they can. The facade can simply be a
TH> JavaBean placed in application scope by a Plug-In, as is done with
TH> the Struts MailReader example. If the facade is based on an
TH> interface, as is done with MailReader, you can change the
TH> implementation of the facade whenever you like.

TH> The Action's job is not to create business objects, but to
TH> *decide* whether an object needs to be created. When any Action
TH> anywhere needs to create a business object, they should be able to
TH> call a method on the facade. Actions should represent the
TH> workflows or "scripts" (to  use Fowler's term) within an
TH> application, not the underlying business operations. The idea is
TH> that the user makes a request, and the Action fulfills that
TH> request, calling whatever business operations it may need along
TH> the way.

TH> Another responsibility of the Action is to select the
TH> resource that will complete the response, usually by rendering a
TH> page. Sometimes this resource may be behind another Action. But
TH> this is not an instance of Action Chaining, since a "resource"
TH> Action (or PageLoader) seeks to complete the response, rather than
TH> fulfill the request.

TH> Another way to think of the facade is as a set of services,
TH> like Web Services. Any time anyone needs to work with a business
TH> object, they should be able to call a service to handle the
TH> implementations details. All the Actions see are signatures.

TH> -Ted.

I think I've understood you...
In my application I use single Actions to serve as "PageLoader" and to
fulfill the request. So, for example, I've two
actions:ResolutionSelectAction and BugCreateAction, each of them
renders the response and fulfills the request. So when user requests
ResolutionSelectAction, in this action depending on value of
"Resolution" that user have selected I can forward him to
BugCreateAction which firstly will serve as "PageLoader".
Is this normal workflow?

P.S. Of course, I use JavaBeans as facade...
P.P.S. [OT] But I still don't know what should I do with transactions in
this situation... If I'll use session object to keep data objects
between actions and save them in last Action, I think my Action will
become too tightly bound...

Thank you for your answer...

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message