Spring also provides a webapp framework. Why would a user bother using Struts with Spring when they could use Spring with Spring?
David --- Ted Husted <[EMAIL PROTECTED]> wrote: > 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] > > __________________________________ Do you Yahoo!? The all-new My Yahoo! - Get yours free! http://my.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
