In Struts 1, we do try to push as much logic as possible into helper classes or business delegates, so that the logic can be tested outside of the container. A good tipping point is whether the logic would make any sense at all outside of the Struts API. If so, then it makes sense to push it into another class so that it can be tested first and then plugged into the Action.
Depending on how the file is read, you might be able to extract that code into a helper object that could be tested outside of Struts. The test would pass in known values, while Struts would pass in values from the request. -- HTH, Ted. * http://www.husted.com/struts/ On 10/4/06, Asad Habib <[EMAIL PROTECTED]> wrote:
I have a Struts action which extracts field values from the request object and then uses these values to set the name of a file which the application reads from. The code responsible for forming the file name currently resides in the action. Is this the best place to put it? This code cannot be considered business logic but rather application logic and I would like to decouple application logic from control logic as much as possible. Is there a particular design pattern that Struts applications rely on to achieve this? Is it sufficient to simply put this code in a helper class? Any input would be appreciated. Thank you. - Asad
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
