Dave,

I'm not sure if you really read my message thoroughly. When I meant
population, I meant for things like drop down lists, not for edit pages
that come pre-populated with existing data to edit. If you always go
back to the same page, then populating the drop down list has to be done
whether you're going to the page directly or after an add/update, so
that's why I was asking about redirecting, I thought you were doing the
update then redirecting to the action that does the setup.

As for the two approaches I've been asking for comments on...they're not
the one below, bu the ones at the end of my email:

1- Put the setup information in the ActionForm class itself (not very
inclined to go for that one).
2- Using a MappingDispatchAction without action chaining. Put the setup
code in common methods in the action class. Configure two mappings for
the same action class that will call two different methods, e.g. prepare
and add. In both methods, I would call the common setup method before
going back to the page, so it's minimal duplicated code (although
duplication is not completely eliminated), but at least it's less
awkward than retieving the form from the request scope by hand.

Of course in number 2 above, I don't mean that the actual database call
is in the action, but the call to the service method.

Thanks

-----Original Message-----
From: Dave Newton [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, May 03, 2006 10:17 PM
To: Struts Users Mailing List
Subject: Re: Is Action Chaining Strongly Discouraged?

Tarek Nabil wrote:
> Do you mean that you're doing a redirect after processing the post?
>   

Who, me? If no, ignore the following.

I'm not sure I understand the question. In a nutshell: for a GET I do
whatever population/misc. stuff I need to do then return the input
forward. For a POST I validate and return the input forward if there are
errors, otherwise I return whatever forward is warranted.

In practice by classes have become more cumbersome than that with
methods designed to be overridden that do pre- and post-processing etc.

> I've been thinking about this action chaining issue for some time 
> since I used it in my last project and it resulted in some code
duplication.
>   

Isn't that bass-ackwards? Even though I really dislike chaining
shouldn't it have less code?

> 1- A prepare action when the page is called directly (a form bean is 
> configured for that one).
> 2- A page action when it's called from another action (no form bean is

> configured to prevent resetting).
>   

*shudder*

If no other reason here's a strong reason to move that logic out of the
actions and into service objects; at least then you're just making calls
rather than duplicating the code. Unless I completely misunderstood you.

> Would anyone care to comment on those two approaches? Does anyone have

> a different approach that I can consider?
>   

At first glance with no clue what you're trying to accomplish it sounds
overly complicated.

Dave

********************************************DISCLAIMER********************************************
This email and any files transmitted with it are confidential and contain 
privileged or copyright 
information. If you are not the intended recipient you must not copy, 
distribute or use this email
or the information contained in it for any purpose other than to notify us of 
the receipt thereof.
If you have received this message in error, please notify the sender 
immediately, and delete this
email from your system.

Please note that e-mails are susceptible to change.The sender shall not be 
liable for the improper
or incomplete transmission of the information contained in this 
communication,nor for any delay in
its receipt or damage to your system.The sender does not guarantee that this 
material is free from
viruses or any other defects although due care has been taken to minimise the 
risk.
**************************************************************************************************

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to