Re: Spring dreaming (was Second call: add generic mapped property to ActionConfig)
On Mon, 29 Nov 2004 10:34:13 -0800 (PST), David Graham [EMAIL PROTECTED] 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 The current Shale version of struts-mailreader requires *one* configuration file (WEB-INF/faces-config.xml), and adding client side validation and/or Tiles *might* add one for each (although that is not a given). For example, Spring config files are only needed if you want to use Spring in addition to JSF -- if you are satisfied with the setter injection support that JSF already provides, you don't need Spring for basic IoC functionality. Tell me again why it is ok for Stuts 1.x to require more configuration files than Shale does :-) Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Spring dreaming (was Second call: add generic mapped property to ActionConfig)
--- Craig McClanahan [EMAIL PROTECTED] wrote: On Mon, 29 Nov 2004 10:34:13 -0800 (PST), David Graham [EMAIL PROTECTED] 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 The current Shale version of struts-mailreader requires *one* configuration file (WEB-INF/faces-config.xml), and adding client side validation and/or Tiles *might* add one for each (although that is not a given). For example, Spring config files are only needed if you want to use Spring in addition to JSF -- if you are satisfied with the setter injection support that JSF already provides, you don't need Spring for basic IoC functionality. Tell me again why it is ok for Stuts 1.x to require more configuration files than Shale does :-) My basic concern is that we're heading down a path that doesn't simplify things for Struts users (including myself in that group) and instead using the next shiny technology in front of us. If Spring and/or JSF simplify using Struts, then I wholeheartedly support using them. But first we need to show how they accomplish that and not just use them because they're cool. Writing Java webapps should be easy. David Craig __ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Spring dreaming (was Second call: add generic mapped property to ActionConfig)
Writing Java webapps should be easy. http://www.hacknot.info/hacknot/action/showEntry?eid=45 Kind of a lengthy read, but it seemed appropriate. - Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Spring dreaming (was Second call: add generic mapped property to ActionConfig)
On Tue, 30 Nov 2004 08:38:54 -0800 (PST), David Graham [EMAIL PROTECTED] wrote: My basic concern is that we're heading down a path that doesn't simplify things for Struts users (including myself in that group) and instead using the next shiny technology in front of us. If Spring and/or JSF simplify using Struts, then I wholeheartedly support using them. But first we need to show how they accomplish that and not just use them because they're cool. Does your definition of easier include writing less Java code? and less stuff in configuration files? If so, please compare the mailreader code in Struts 1.x versus the Shale-ized version. You'll find substantial improvements. If those aspects are not included in your definition, I'd be curious what is. Writing Java webapps should be easy. I'd say as easy as possible, but no easier :-) David Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Spring dreaming (was Second call: add generic mapped property to ActionConfig)
+ 1 .V David Graham wrote: If Spring and/or JSF simplify using Struts, then I wholeheartedly support using them. But first we need to show how they accomplish that and not just use them because they're cool. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Spring dreaming (was Second call: add generic mapped property to ActionConfig)
Good points, but there do exist tools to somewhat aide in configuration. True, not all configs have tools for them, and not all editors/IDEs support all tools ... but the tools do exist none-the-less :-) ... 'course, it's still nice to know the format of a config file, in case there's some feature you can't realize using a tool. WSAS tells me, for example, that I have a broken link in my config file as a result of referencing a tile through the forward attribute of an action. It annoys me, but, of course, it works fine (Seems WSAD 5.1.1 only supports Struts 1.1). I can imagine a circumstance where a config could change by adding an attribute or some other thing so that the tool couldn't edit these pieces. Eddie - Original Message - From: David Graham [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, November 29, 2004 12:34 PM Subject: Re: Spring dreaming (was Second call: add generic mapped property to ActionConfig) 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 --- avast! Antivirus: Outbound message clean. Virus Database (VPS): 0448-1, 11/26/2004 Tested on: 11/30/2004 12:22:38 PM avast! - copyright (c) 2000-2004 ALWIL Software. http://www.avast.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Spring dreaming (was Second call: add generic mapped property to ActionConfig)
Very applicable actually :) Let's look it this way - what types of information needs to go into configuration? I see the following types: 1. Action/Backing bean definitions. Perferably support for connecting with business objects. 2. Form/field definitions and validations. 3. ActionForwards/Navigation My understanding how these are handled by several major frameworks: Struts 1. Actions defined in struts-config.xml. No support for linking to business objects. 2. Forms defined in struts-config. Validations in validation-rules.xml 3. ActionForwards in struts-config.xml, no support for navigation JSF 1. Backing beans defined in faces-config.xml. Integration with Spring to connect to bus objects. 2. Forms and validations defined in the JSP's. No support for 1:M forms (save custom components) 3. No action forwards as page based. Navigation information stored in faces-config.xml Tapestry 1. Beans definied in each page's specification xml file. Support for bus object linking with hivemind. 2. Form fields defined in page spec file. No support for 1:M forms (save custom components). 3. No action forwards as page based. No explicit navigation configuration. One could argue Tapestry was the simplest, however it could also be argued the opposite since each page needs its own xml configuration file. The question is what and where do we want the user to be able to configure. On one extreme of configuration, NanoWeb/NanoWar require no configuration as the framework handles everything. On the other side, Struts seems to require configuration for everything. The better approach depends on your objectives and requirements, as well as personal taste. I'd argue Struts should continue to provide the maximum flexibility, but search for ways to provide intelligent defaults wherever possible to allow the new developer to be able to pick up Struts quickly, yet allow the advanced user the capability to customize the framework to their needs. I like Ted's one DTD idea to bring everything together, yet provide import-type capability to let those that perfer multiple files split out sections. I also like Spring's idea of separating the configuration from the code, to allow for alternate configuration schemes which may not even use XML. I think we should continue to strive for flexibility to allow innovative projects like Beehive to more easily explore new ideas and techniques. Don On Tue, 30 Nov 2004 10:47:23 -0600, Durham David R Jr Contr 805 CSPTS/SCE [EMAIL PROTECTED] wrote: Writing Java webapps should be easy. http://www.hacknot.info/hacknot/action/showEntry?eid=45 Kind of a lengthy read, but it seemed appropriate. - Dave - 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]
Re: Spring dreaming (was Second call: add generic mapped property to ActionConfig)
While I'm one who has had good experiences with Spring's BeanFactory for managing my business objects, maybe we should focus first on defining what Struts is and what needs to be configured. This would allow us to move more flexibly to various configuration approaches, or conceivably support more than one. I've been thinking for a while that we should stop storing so many things directly in the ServletContext and instead, define a Struts object which would hold these things. I've mentioned this obliquely a few times and not gotten much response, so maybe no one else likes the idea. Or maybe it's been too oblique. Benefits of something like this would be reducing dependencies on the Servlet API and providing a better environment for testing. Is there any interest in this, or is it cracked? If it's not cracked, we might also take a longer-term look at abstracting the session, which seems tedious, but has some of the same issues. We may never need to truly abstract away the HttpServletRequest, since the Chain context will have the same lifecycle and serve about the same purpose. Now, then: This whole thread started as a different question and was motivated by an earlier question. Assuming that we continue to use Digester to instantiate and populate ActionConfig objects, I would like to add a generic mapped property to ActionConfig so that rather than writing trivial and boring subclasses of ActionConfig, one can simply set properties on it. I'd make it a Properties because I'd expect it to have strings, but I would accept arguments to make it a map instead with the idea that later other Objects might get in there. (Ugh, but all that casting!) Assuming no one objects in the next day or two, I'll assume it's ok, and I'll call it props, just because I would rather not screw around waiting for another name. The motivation for this was a perceived flaw in the ChainAction and chain DispatchAction classes which won't know in which catalog to look for the command either one is supposed to execute. A generic property map would allow the ChainAction to define the name of the properties it wants for its configuration, rather than requiring that its ActionConfig implement some specific interface just to get one more property in. Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com Narrow minds are weapons made for mass destruction -The Ex
Re: Spring dreaming (was Second call: add generic mapped property to ActionConfig)
--- Joe Germuska [EMAIL PROTECTED] wrote: snip This sounds like a good idea to me. I generally avoid Properties in favor of Maps in external interfaces but the casting really is a pain. Properties is a Map so you could store any old object in there anyways. David Now, then: This whole thread started as a different question and was motivated by an earlier question. Assuming that we continue to use Digester to instantiate and populate ActionConfig objects, I would like to add a generic mapped property to ActionConfig so that rather than writing trivial and boring subclasses of ActionConfig, one can simply set properties on it. I'd make it a Properties because I'd expect it to have strings, but I would accept arguments to make it a map instead with the idea that later other Objects might get in there. (Ugh, but all that casting!) Assuming no one objects in the next day or two, I'll assume it's ok, and I'll call it props, just because I would rather not screw around waiting for another name. The motivation for this was a perceived flaw in the ChainAction and chain DispatchAction classes which won't know in which catalog to look for the command either one is supposed to execute. A generic property map would allow the ChainAction to define the name of the properties it wants for its configuration, rather than requiring that its ActionConfig implement some specific interface just to get one more property in. Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com Narrow minds are weapons made for mass destruction -The Ex __ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Spring dreaming (was Second call: add generic mapped property to ActionConfig)
On Tue, 30 Nov 2004 17:15:51 -0600, Joe Germuska wrote: I've been thinking for a while that we should stop storing so many things directly in the ServletContext and instead, define a Struts object which would hold these things. I've mentioned this obliquely a few times and not gotten much response, so maybe no one else likes the idea. Or maybe it's been too oblique. Benefits of something like this would be reducing dependencies on the Servlet API and providing a better environment for testing. Like it? I implemented it two years nine months ago :) * http://svn.apache.org/viewcvs.cgi/struts/trunk/src/share/org/apache/struts/config/ConfigHelperInterface.java?rev=48889view=markup It's also mentioned on the proposed updates to the Roadmap. * http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]msgNo=29427 under the moniker ViewContext. I was going to try and work on updating the website tonight, but my flight was delayed, and I might not get to it. I do think we should be passing a Struts API bean out to the view, which could also include a context for arbitrary properties. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Spring dreaming (was Second call: add generic mapped property to ActionConfig)
On Tue, 30 Nov 2004 17:15:51 -0600, Joe Germuska [EMAIL PROTECTED] wrote: While I'm one who has had good experiences with Spring's BeanFactory for managing my business objects, maybe we should focus first on defining what Struts is and what needs to be configured. This would allow us to move more flexibly to various configuration approaches, or conceivably support more than one. I've been thinking for a while that we should stop storing so many things directly in the ServletContext and instead, define a Struts object which would hold these things. I've mentioned this obliquely a few times and not gotten much response, so maybe no one else likes the idea. Or maybe it's been too oblique. Benefits of something like this would be reducing dependencies on the Servlet API and providing a better environment for testing. +1 for defining a context, reducing servlet API dependencies, and making the framework more testable. :-) -- Martin Cooper Is there any interest in this, or is it cracked? If it's not cracked, we might also take a longer-term look at abstracting the session, which seems tedious, but has some of the same issues. We may never need to truly abstract away the HttpServletRequest, since the Chain context will have the same lifecycle and serve about the same purpose. Now, then: This whole thread started as a different question and was motivated by an earlier question. Assuming that we continue to use Digester to instantiate and populate ActionConfig objects, I would like to add a generic mapped property to ActionConfig so that rather than writing trivial and boring subclasses of ActionConfig, one can simply set properties on it. I'd make it a Properties because I'd expect it to have strings, but I would accept arguments to make it a map instead with the idea that later other Objects might get in there. (Ugh, but all that casting!) Assuming no one objects in the next day or two, I'll assume it's ok, and I'll call it props, just because I would rather not screw around waiting for another name. The motivation for this was a perceived flaw in the ChainAction and chain DispatchAction classes which won't know in which catalog to look for the command either one is supposed to execute. A generic property map would allow the ChainAction to define the name of the properties it wants for its configuration, rather than requiring that its ActionConfig implement some specific interface just to get one more property in. Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com Narrow minds are weapons made for mass destruction -The Ex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Spring dreaming (was Second call: add generic mapped property to ActionConfig)
Yep, that's a lot of what I had in mind. But I had been thinking that there was call for some more functionality in the controller layers as well as in the view. The interface is read-only, which is right for a view, but maybe incomplete in other layers. But I'm ready for bed now, so I will have to sleep on it before I could say just what write type methods I think there would need to be. Joe At 11:16 PM -0500 11/30/04, Ted Husted wrote: On Tue, 30 Nov 2004 17:15:51 -0600, Joe Germuska wrote: ÝI've been thinking for a while that we should stop storing so many Ýthings directly in the ServletContext and instead, define a ÝStruts object which would hold these things. ÝI've mentioned this Ýobliquely a few times and not gotten much response, so maybe no one Ýelse likes the idea. ÝOr maybe it's been too oblique. ÝBenefits of Ýsomething like this would be reducing dependencies on the Servlet ÝAPI and providing a better environment for testing. Like it? I implemented it two years nine months ago :) * http://svn.apache.org/viewcvs.cgi/struts/trunk/src/share/org/apache/struts/config/ConfigHelperInterface.java?rev=48889view=markup It's also mentioned on the proposed updates to the Roadmap. * http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]msgNo=29427 under the moniker ViewContext. I was going to try and work on updating the website tonight, but my flight was delayed, and I might not get to it. I do think we should be passing a Struts API bean out to the view, which could also include a context for arbitrary properties. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com Narrow minds are weapons made for mass destruction -The Ex
Spring dreaming (was Second call: add generic mapped property to ActionConfig)
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Spring dreaming (was Second call: add generic mapped property to ActionConfig)
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. 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Spring dreaming (was Second call: add generic mapped property to ActionConfig)
--- 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: [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]
Re: Spring dreaming (was Second call: add generic mapped property to ActionConfig)
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: [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]
Re: Spring dreaming (was Second call: add generic mapped property to ActionConfig)
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]
Re: Spring dreaming (was Second call: add generic mapped property to ActionConfig)
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:
Re: Spring dreaming (was Second call: add generic mapped property to ActionConfig)
Cause ours is better...duh... ;) Don 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Spring dreaming (was Second call: add generic mapped property to ActionConfig)
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
