I am not sure I understand when you say: Don't make them static > if they depend on session or request state, as you'll shoot yourself > in the foot due to the implicit threading in the app server.
Why can't I pass in a request object to a static method? As long as it doesn't depend on other static members that may change I should be ok, right? I decided to go with the helper class but I am curious about this static method and request/session object relation that you mentioned. Thanks! On 7/18/05, Ed Griebel <[EMAIL PROTECTED]> wrote: > On 7/18/05, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > > I used to do a lot of this back when I wasn't as clear on why Actions > > shouldn't contain actual code (this started when I was using a custom > > framework my company build that had examples that didn't make it clear > > you shouldn't do this). > > > > Exactly what I've ran into as well! Most of the time I end up > refactoring almost all non-trivial logic into separate classes because > I have needed them elsewhere. > > What the original poster may be able to get away with is making the > method public static in the action. It's a hack, but it will get you > running quickly. Once you get it tested and working it's easy to move > the method(s) to a helper class, espcially if you are using an IDE > that supports refactoring like Eclipse or IDEA. Don't make them static > if they depend on session or request state, as you'll shoot yourself > in the foot due to the implicit threading in the app server. > > Good luck! > -ed > > --------------------------------------------------------------------- > 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]
