Spring is designed to instantiate any given object graph, which should include the Struts configuration objects. It would seem to follow that we could configure everything in Struts from a Spring configuration file. If so, then we would not be adding another framework, but using Spring in lieu of the Digester and an assortment of custom factories.
Is not Spring MVC (which is very much like Struts) configured from a Spring configuration file? Ideally, an application should be able to use as many, or as few, configuration files as it likes. -Ted. On Mon, 29 Nov 2004 10:47:07 -0800, Don Brown wrote: > Good point, however the use of intelligent defaults would simplify > things. I'd see it this way: > > 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: >>> >>> >>>> 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, >>>> >>>> >>> #5, >>> >>> >>>> and #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 >>>> >>>> >>> context/BeanFactory >>> >>> >>>> file 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 robust >>>>>> configuration/initialization, the more I think we are >>>>>> going to realize Spring already does this and does it >>>>>> better. >>>>>> >>>>>> >>>>> I suspect you're right, as I have come to prefer Spring's >>>>> >>>>> >>> BeanFactory >>> >>> >>>>> 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: dev- >>>>[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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
