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]
__________________________________
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
