The JavaBean design pattern is as good as any. Encapsulate the functionality as an object, where attributes like the filename are represented by get and set methods. Instantiate the object, set the filename property, and call an execute or process method to fetch whatever it is you are after. If it's more convenient, provide an alternate constructor that accepts the filename and invokes the setter.
FileProcessor fileProcessor = new FileProcessor(fileName); whatever = fileProcessor.process(); The underlying benefit being that JavaBean helpers can be tested outside of Struts 1 and without a container. Some people cast such things as services. Here you are processing a file, but it's no different than fetching a shopping cart, or other entity people color as services. A common example of reading in a file to would be a data mapper service, like iBATIS, or an object factory service, like Spring. Both read and process files that, in turn, provide other services to the application. Of course, Struts 1 does the same sort of thing with its struts-config. Speaking of iBATIS and Spring, In the SportsForge application for Struts 2 (an early work in progress), we use a ServiceConfig object to read in the iBATIS configuration. In unit tests, we create the ServiceConfig directly as part of the Setup, so that each test get a clean copy of the configuration. In the runtime application, we let Spring instantiate the configuration as a singleton. SeviceConfig class * http://tinyurl.com/ropjw Unit Test Configuration * http://tinyurl.com/or426 Spring Configuration * http://tinyurl.com/m5je3 In the latter case, Spring creates the Mapper configruation and then injects it into the individual Service objects (which the S2 Action class access by id). Each service object then has a reference to the DataMapper and can call it directly. (In the XML source, the mapper is actually injected into a base ServiceClient object, and the other objects then inherit the reference.) Of course, in most cases, instantiating a JavaBean helper directly from the Action source code works just fine, and since Struts 1 Actions are singletons, you really only have to do it once per file. -- HTH, Ted. * http://www.husted.com/struts/ On 10/5/06, Asad Habib <[EMAIL PROTECTED]> wrote:
Hello Ted. Thanks for your response. Is there a design pattern that incorporates these helper classes? Would it be sufficient for me to call this class an action helper? The concept of a business delegate does not apply in this case since the code in question is not related to a business object. If you can point me to some examples that have a similar architecture, that would certainly help. Also, as Frank mentioned in his response, I could populate a VO in my action and then pass it on to a helper class to process. Is it good Struts practice to access VOs from actions? Any help would be appreciated. Thanks. - Asad On Thu, 5 Oct 2006, Ted Husted wrote: > 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]
