Here is code, as opposed to pretty pictures -- LOL ;-)
This is intended to demonstrate how simple Had is in contrast to
normal Service Locator or Inversion of Control (Dependency Injection)
frameworks. Remember, THIS IS ALL THE CODE. There are no
NanoContainers. Not XML. No Config classes,
This may have been lost in the (US) holiday shuffle, or because it
was tucked into a subject line which might not have indicated a
suggestion for a change to a relatively core part of Struts. So I
just thought I'd air it one more time before I make any changes to
ActionConfig.
Note that the
How would this work with digester? As I understand it, digester is the
one that actually populates the action config, and then only at init time.
I sure like the idea, but don't know about the naming style. What about
foo.bar where foo corresponds to setFoo(Map m) and foo.bar calls
If I'm reading the code right, your factory for any given class has
to know a bunch of nitty gritty details in order to implement the
transferState() method, right? So, whenever I add new state
information to the application class, I have to update transferState()
as well?
I don't see any
At 8:48 AM -0800 11/29/04, Don Brown wrote:
How would this work with digester? As I understand it, digester is
the one that actually populates the action config, and then only at
init time.
I sure like the idea, but don't know about the naming style. What
about foo.bar where foo corresponds
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
Thanks for this thoughtful response, Craig. Very helpful. Notes are within:
On Mon, 29 Nov 2004 09:02:04 -0800, Craig McClanahan [EMAIL PROTECTED] wrote:
If I'm reading the code right, your factory for any given class has
to know a bunch of nitty gritty details in order to implement the
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
On Mon, 29 Nov 2004 15:04:48 -0800, Dakota Jack [EMAIL PROTECTED] wrote:
Thanks for this thoughtful response, Craig. Very helpful. Notes are within:
On Mon, 29 Nov 2004 09:02:04 -0800, Craig McClanahan [EMAIL PROTECTED]
wrote:
If I'm reading the code right, your factory for any given
Just a few notes and more later after some thought:
On Mon, 29 Nov 2004 17:01:43 -0800, Craig McClanahan [EMAIL PROTECTED] wrote:
On Mon, 29 Nov 2004 15:04:48 -0800, Dakota Jack [EMAIL PROTECTED] wrote:
Yup! Dang! LOL Nothing is free, is it? I have changed the factory
transfer state
On Mon, 29 Nov 2004 17:36:09 -0800, Dakota Jack [EMAIL PROTECTED] wrote:
I am not sure what you mean by transparently swap. IoC requires
fairly extensive configuration for this transparency. I don't see
what is transparent about the IoC setting of an implementation at all.
Am I missing
Thanks, Craig. I think there might be a misunderstanding. See within.
On Mon, 29 Nov 2004 18:32:06 -0800, Craig McClanahan [EMAIL PROTECTED] wrote:
On Mon, 29 Nov 2004 17:36:09 -0800, Dakota Jack [EMAIL PROTECTED] wrote:
I am not sure what you mean by transparently swap. IoC requires
Just a lurker; I'm trying to follow along but I still don't get it.
Dakota Jack wrote:
You can tell me to use create on demand instead, but then I don't
need anything fancier than an IoC framework that lets me reconfigure
on the fly.
And, current IoC approaches provide me other important
19 matches
Mail list logo
