If I were to add something like this to Struts (and I have enough interest in this idea that I'd love to persue it, assuming there is some general interest), one of the requirements in my mind would be the ability to call any number of setup methods per mapping.
For instance, maybe I have a page with 10 different dropdowns. Maybe I determine that the way I want to implement that setup is to have ten different methods in my setup class and specify them all to execute in the mapping. Sure, I could call all ten of them from the constructor, but that just *feels* like a bit of a hack to me. I'd prefer a more IoC-esque approach, and this feels like the exact opposite. I'd want to be able to explitidly declare the ten methods I want executed (and in the stated order of course) rather than having to code that functionality into the setup class itself, which is what I'd be forced to do in the constructor (ditto for a static block).
There is a debate in my mind whether the setup class should have to implement some given interface... It makes sense to do so because then Struts can be sure the class is of an appropriate type for the task. But, to allow for multiple setup methods the interface would have to be defined to include setupMethod1(), setupMethod2(), setupMethod3() and so on. That's pretty obviously a bad design. So, I imagine the interface would pretty much just be a tag interface, and we would have to assume that if the developer implements the interface, then whatever methods are present in the class are meant for setup. Like I said though, there's a bit of debate in my own head on this point right now.
-- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com
Leon Rosenberg wrote:
... I figured you'd specify the class and method to call, although even easier would be to write an actual SetupAction class, or something along those lines, with a known interface that all these classes would have to implement, then you would just specify the class and Struts would know what method to call.
Erm, what about the constructor? Or the static{} part?
Regards Leon
--------------------------------------------------------------------- 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]
