Spring itself is an object factory. Spring MVC is a set of objects that the Spring team developed as their vision of a web application framework. Some people like it. Some people don't.
A webapp framework, like Struts or Spring MVC, isn't about what technology instantiates the objects, but how the instantiated objects interact. Spring has already added Don's Struts-Spring extension to the distribution, which indicates that Struts has a strong following in the Spring community. The nice part about Spring is that, like Chain, it is also useful on the business layer. -Ted. On Mon, 29 Nov 2004 15:44:39 -0800 (PST), David Graham wrote: > 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: dev- >>>>>[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: dev- >>>>[EMAIL PROTECTED] For additional commands, e- >>>> mail: [EMAIL PROTECTED] >>>> >>>> >>> ---------------------------------------------------------------- >>> ---- - 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! - Get yours free! > 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]
