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]
