In addition to supporting Struts integration, the Spring folks have also integrated Spring with JSF's expression evaluation APIs, so you can transparently create or access Spring beans like any JSF managed bean.
Craig On Mon, 29 Nov 2004 19:39:12 -0500, Ted Husted <[EMAIL PROTECTED]> wrote: > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
