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
--- 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
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,
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
+ 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,
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
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.
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
--- 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
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
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
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
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
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 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
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
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
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
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,
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
20 matches
Mail list logo
