Just thought I'd through an argument out there against using the xml configuration approach as food for thought.
On my current application, I have around 12 struts modules. Each is using dynaActionForms, 3 or 4 plugins, and ranging from 10-50 actions. I have several developers who do a great job creating jsps, actions, tiles and struts config entries, etc. They definitely don't live in the world of the RequestProcessor level stuff (and don't want to), as they have to much to already worry about. I think if to many more complexities are added to an already huge struts config file, then that just makes life difficult for your basic struts programmer just trying to get his jsps to display, validate properly, and reach the action code ok. It just seems that most average struts developers aren't working at the level of extending the RequestProcessor, and therefore don't even want to see a bunch of potentially complicated looking xml configuration code. It seems like to me that if you have average joe struts developer out there, and he wants to use 3 diffent extentions, you are going to only increase the traffic on the struts user list with him trying to figure out the order of the processXxx methods, etc. Shouldn't that complexity be left to all you gurus hanging out on this mailing list to figure out in code? =:0) Besides, the complexity seems like it is nearly impossible to manage with the more extenstions you try to add into the mix. Why not focus instead on pulling in the best of these features into the core of struts, and using action mappings, etc. to provide more options on what to use (like validation), etc. :) Just more food for thought. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
