Re: RequestProcessor and execute method
See, I thought of going the same route, but I didn't want it to be the burden of a task controller (Action). It just didn't seem to make sense at that level, but I can see you struggled with the same uneasiness I did. You're right, what we're both mimicking here is doGet and doPost of HttpServlet. On 5/24/06, Dave Newton <[EMAIL PROTECTED]> wrote: Monkeyden wrote: > I'm wondering if anyone else has done something different and/or more > practical. Different, yes; more practical, probably not. In the past I've just used a base Action class that differentiated between GET and POST requests and called executeGet and executePost methods. Interspersed amongst that are over-ridable methods to do pre- and post-processing. I haven't decided whether or not I'd want to move that into the request processor as you have so it's just languished for a couple of years now :/ Haven't done any new apps in Struts for over a year so it hasn't been an issue--I kind of like the idea of having it further back in the chain, though. I don't like having different URLs though. Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RequestProcessor and execute method
I use eventDispatcher. Default to present and others to submit. http://wiki.apache.org/struts/DataEntryForm someone post this url in this mailing list before. El 24/05/2006, a las 20:01, Monkeyden escribió: I recently came to the conclusion that I didn't like the hidden form field markers and conditional logic used in the Action.execute() method, to determine whether the user was performing the initial fetch of an ActionMapping or submitting. The solution I came up with was to extend the Struts RequestProcessor's processActionPerform() method, to parse the request uri of the ActionMapping, to determine which (new) method to call on the Action (doSelect or doSubmit). Obviously this forces a naming convention for the value of the ActionMapping path attributes (path="/myAction/select" and path="/myAction/submit"). I then extended Action, to define these as abstract methods. I found that this seemed very natural, reduced code bloat and made a clear distinction between disparate request types. I'm wondering if anyone else has done something different and/or more practical. -- Jorge Martín Cuervo email: [EMAIL PROTECTED] voz: +34 660 026 384 -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RequestProcessor and execute method
Monkeyden wrote: > I'm wondering if anyone else has done something different and/or more > practical. Different, yes; more practical, probably not. In the past I've just used a base Action class that differentiated between GET and POST requests and called executeGet and executePost methods. Interspersed amongst that are over-ridable methods to do pre- and post-processing. I haven't decided whether or not I'd want to move that into the request processor as you have so it's just languished for a couple of years now :/ Haven't done any new apps in Struts for over a year so it hasn't been an issue--I kind of like the idea of having it further back in the chain, though. I don't like having different URLs though. Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
