1. struts-config.xml - Defines action mappings. Default config could use wildcards to cover 90% of mappings. Ted's "extends" idea would also help keep it small.
2. forms.xml - Combines dyna action forms and validator rules into one logical document. I suppose this could be combined into struts-config.xml. If so, it would follow Ted's idea of one config file DTD to rule them all.
3. spring.xml - Yes, it does define actions, plugins, etc separately from struts-config.xml, but this allows you to more easily hook application classes into your implementations. For example, you can write an Action that can automatically get reference(s) to your services layer or DAO layer. This is important as it not only makes things simpler for the user, but is yet another step that removes the user from ever having to work with the application scope. One feature I really like about Tapestry (probably JSF too) is they don't put all sorts of application and framework objects in shared scopes.
Tiles could probably be woven into struts-config.xml, and I'm still not convinced there is much to be gained from a Struts and JSF combination (outside the usual migration arguments).
Don
David Graham wrote:
--- Craig McClanahan <[EMAIL PROTECTED]> wrote:
I agree with Don's assessment, but wanted to add an FYI note -- Shale does zero-config for #3 (because the mapping between a JSP page and the corresponding ViewController is implicit), and doesn't require #1 unless you need it for doing Commons Validator stuff.
Simpler is definitely better.
But is adding yet another framework to Struts simplifying anything for the user or just for us developers? If we add Spring, we would need to know the following to write a Struts webapp: 1. struts-config.xml 2. validator-rules.xml 3. spring.xml (or whatever they call the config file) 4. possibly tiles-config.xml 5. possibly jsf config files
How is learning and remembering up to 5 different configuration files better for the user? If I was put in this position, I would seriously consider other ways of writing Java webapps.
David
Craig
On Mon, 29 Nov 2004 10:03:16 -0800, Don Brown <[EMAIL PROTECTED]> wrote:
#5,struts-config.xml accomplishes the following tasks:
1. Defines form models 2. Defines and configures Actions 3. Defines and configures mappings of actions 4. Defines and configures plugins 5. Defines and configures message resources 6. Defines and configures request processor
I see Spring vastly improving, if not completely replacing, #2, #4,
context/BeanFactoryand #6. It could even be argued #1 should be moved into a form definition file that integrates validator field configuration.
Therefore, I'd imagine a Springified Struts only needing
struts-config.xml for #3, defining action mappings, with probably
another configuration element to point to the Spring
BeanFactoryfile for the module (loaded as a child of a global Spring context/BeanFactory) and the bean id's the request process, message resources, and plugins can be found under.
Don
Joe Germuska wrote:
<snip />
The more we go down this road of more robustI suspect you're right, as I have come to prefer Spring's
configuration/initialization, the more I think we are going to
realize Spring already does this and does it better.
to Digester for this kind of thing. Have you ever looked at configuring Struts completely using Spring? It might be an interesting exercise, along with possibly coming up with an XSLT process to make current Struts config files usable with Spring!
Joe
--------------------------------------------------------------------- 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]
__________________________________ Do you Yahoo!? The all-new My Yahoo! - What will yours do?
http://my.yahoo.com
--------------------------------------------------------------------- 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]
