On Wed, February 2, 2005 1:10 pm, Joe Germuska said:This actually stimulated another thought. Perhaps instead of overriding process validate, you could arrange to have your ActionMappings dynamically instantiated with the correct value for "input" (assuming that you can know it before you do the validation.)
Actually, now you've stimulated a though in me! :)
Correct me if I'm wrong, but processPreprocess() fires BEFORE processValidate(), correct? In that case, since I can in fact determine the input after processPreprocess() fires, I can simply call setInput() on the mapping with the new value, and everything should work as expected.
Sound about right to you Joe?
The order in which request processor "template" methods are called is laid out at
http://struts.apache.org/userGuide/building_controller.html#request_processor
you don't yet have an ActionMapping when processPreprocess() fires, but I guess you could pre-compute something and put it in the request scope, and then get it out later.
Of course, you can see it in all its glory at http://svn.apache.org/viewcvs.cgi/struts/core/trunk/src/share/org/apache/struts/action/RequestProcessor.java?view=markup
(hooray for fixed viewCVS!)
> I still think using the ComposableRequestProcessor is an easier solution!
You didn't answer the question I was hoping you would though :) Is that class based on the CoR-based Struts codebase? If so, while I in no way diagree with you that it's probably the better/easier solution, I'm not quite ready to move to the CoR paradigm with this yet.
yeah, I sent this before I saw that. The ComposableRequestProcessor is the subclass of RequestProcessor which delegates to a commons-chain command for processing, so if you're not ready, you're not ready.
Joe
--
Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "Narrow minds are weapons made for mass destruction" -The Ex
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
