You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Joe Germuska <Jo...@Germuska.com> on 2004/11/29 18:07:02 UTC
Re: Second call: add "generic" mapped property to ActionConfig
(was Re: [chain] ChainAction and o.a.s.chain.legacy.DispatchAction)
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 to setFoo(Map m) and foo.bar
>calls m.put("bar")
The example I provided (repeated below) is written according to
Digester's built-in support for "mapped properties".
To support the naming style you suggest would require making
BeanUtils understand that syntax. I would want to get some other
opinions about the implications of that before proposing it, although
I don't have a great love for the way it is now.
>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
>>><action-mapping path="/foo"
>>>type="org.apache.struts.chain.legacy.ChainAction">
>>> <set-property name="props(command-name)" value="my-command" />
>>> <set-property name="props(catalog-name)" value="my-catalog" />
>>> ...
>>></action>
>>>
>>>public class ActionConfig {
>>>...
>>> private java.util.Properties props = new java.util.Properties();
>>> public void setProps(String key, String value) {
>>>this.props.setProperty(key,value); }
>>> public String getProps(String key) { return this.props.getProperty(key); }
>>>
>>>...
>>>}
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
Re: Roadmaps (was Spring dreaming ...)
Posted by Craig McClanahan <cr...@gmail.com>.
On Tue, 30 Nov 2004 07:45:17 -0500, Ted Husted <hu...@apache.org> wrote:
>
> Speaking of todos, is there more to be done on the struts-faces taglib? Or is that ready for a release vote?
>
There are two outstanding bugs ... 32014 and 32370. The latter is
fairly straightforward, the former is a must fix (the current wrapper
that was added for MyFaces compatibility breaks the servlet API rules,
but changing that makes Tiles not work). I'd also like to see MyFaces
get to the point where it can actually run with Struts (since lots of
people will try it) -- as of 1.0.7 they still had some bugs (which I
filed in their SF bugtracking system a while back).
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Spring dreaming (was Second call: add "generic" mapped property to ActionConfig)
Posted by Craig McClanahan <cr...@gmail.com>.
On Tue, 30 Nov 2004 08:38:54 -0800 (PST), David Graham
<gr...@yahoo.com> 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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Spring dreaming (was Second call: add "generic" mapped property
to ActionConfig)
Posted by Vic <vi...@friendvu.com>.
+ 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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Roadmaps (was Spring dreaming ...)
Posted by Ted Husted <hu...@apache.org>.
On Tue, 30 Nov 2004 00:34:54 -0800, Craig McClanahan wrote:
>�Tell me again why it is ok for Stuts 1.x to require more
>�configuration files than Shale does :-)
It's not OK, which is why the latest proposed roadmap mentions combining the configurations. All three configurations support partial and multiple files, so combining them should not be difficult. People could then use the existing files or combined then in anyway they pleased. (I forget why we didn't do this in the first place.) I'll take a minute to update the website tonight, before getting on to my other todo items.
Speaking of todos, is there more to be done on the struts-faces taglib? Or is that ready for a release vote?
The struts-faces taglib seems like a great way to introduce people to JSF on the frontend.
Hopefully, the work on Struts 1.3.x will enable people to migrate the guts of Struts Actions to Chain Commands. In terms of providing a clear migration path, Chain is important since it could work equally well for Struts or JSF applications. Then, there will be a way for people to migrate both pages and Actions, and the JSF leap becomes a baby step.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Spring dreaming (was Second call: add "generic" mapped property to ActionConfig)
Posted by David Graham <gr...@yahoo.com>.
--- Craig McClanahan <cr...@gmail.com> wrote:
> On Mon, 29 Nov 2004 10:34:13 -0800 (PST), David Graham
> <gr...@yahoo.com> wrote:
> > --- Craig McClanahan <cr...@gmail.com> 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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Spring dreaming (was Second call: add "generic" mapped property to ActionConfig)
Posted by Craig McClanahan <cr...@gmail.com>.
On Mon, 29 Nov 2004 10:34:13 -0800 (PST), David Graham
<gr...@yahoo.com> wrote:
> --- Craig McClanahan <cr...@gmail.com> 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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Spring dreaming (was Second call: add "generic" mapped property to ActionConfig)
Posted by Eddie Bush <ea...@swbell.net>.
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" <gr...@yahoo.com>
To: "Struts Developers List" <de...@struts.apache.org>; <cr...@apache.org>
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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Spring dreaming (was Second call: add "generic" mapped property
to ActionConfig)
Posted by Don Brown <mr...@twdata.org>.
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 <hu...@apache.org> 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 <cr...@gmail.com> 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
>>>>><mr...@twdata.org> 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-
>>>>>>unsubscribe@struts.apache.org For additional commands, e-
>>>>>>mail: dev-help@struts.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>----------------------------------------------------------------
>>>>>----- To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>>>For additional commands, e-mail: dev-help@struts.apache.org
>>>>>
>>>>>
>>>>__________________________________
>>>>Do you Yahoo!?
>>>>The all-new My Yahoo! - What will yours do?
>>>>http://my.yahoo.com
>>>>
>>>>------------------------------------------------------------------
>>>>--- To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org For
>>>>additional commands, e-mail: dev-help@struts.apache.org
>>>>
>>>>
>>>>
>>>--------------------------------------------------------------------
>>>- To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org For
>>>additional commands, e-mail: dev-help@struts.apache.org
>>>
>>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>>
>>
>
>
>
>
>__________________________________
>Do you Yahoo!?
>The all-new My Yahoo! - Get yours free!
>http://my.yahoo.com
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>For additional commands, e-mail: dev-help@struts.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Spring dreaming (was Second call: add "generic" mapped property to ActionConfig)
Posted by Craig McClanahan <cr...@gmail.com>.
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 <hu...@apache.org> 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 <hu...@apache.org> 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 <cr...@gmail.com> 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
> >>>>> <mr...@twdata.org> 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-
> >>>>>> unsubscribe@struts.apache.org For additional commands, e-
> >>>>>> mail: dev-help@struts.apache.org
> >>>>>>
> >>>>>>
> >>>>> ------------------------------------------------------------
> >>>>> ---- ----- To unsubscribe, e-mail: dev-
> >>>>> unsubscribe@struts.apache.org For additional commands, e-
> >>>>> mail: dev-help@struts.apache.org
> >>>>
> >>>>
> >>>> __________________________________
> >>>> Do you Yahoo!?
> >>>> The all-new My Yahoo! - What will yours do?
> >>>> http://my.yahoo.com
> >>>>
> >>>> --------------------------------------------------------------
> >>>> ---- --- To unsubscribe, e-mail: dev-
> >>>> unsubscribe@struts.apache.org For additional commands, e-
> >>>> mail: dev-help@struts.apache.org
> >>>>
> >>>>
> >>> ----------------------------------------------------------------
> >>> ---- - To unsubscribe, e-mail: dev-
> >>> unsubscribe@struts.apache.org For additional commands, e-mail:
> >>> dev-help@struts.apache.org
> >>
> >>
> >> ------------------------------------------------------------------
> >> --- To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org For
> >> additional commands, e-mail: dev-help@struts.apache.org
> >
> >
> > __________________________________
> > Do you Yahoo!?
> > The all-new My Yahoo! - Get yours free!
> > http://my.yahoo.com
> >
> >
> > --------------------------------------------------------------------
> > - To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org For
> > additional commands, e-mail: dev-help@struts.apache.org
>
>
> ---------------------------------------------------------------------
>
>
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Spring dreaming (was Second call: add "generic" mapped property to ActionConfig)
Posted by Ted Husted <hu...@apache.org>.
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 <hu...@apache.org>�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 <cr...@gmail.com>�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
>>>>>�<mr...@twdata.org>�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-
>>>>>>�unsubscribe@struts.apache.org For additional commands, e-
>>>>>>�mail: dev-help@struts.apache.org
>>>>>>
>>>>>>
>>>>>�------------------------------------------------------------
>>>>>�---- ----- To unsubscribe, e-mail: dev-
>>>>>�unsubscribe@struts.apache.org For additional commands, e-
>>>>>�mail: dev-help@struts.apache.org
>>>>
>>>>
>>>>�__________________________________
>>>>�Do you Yahoo!?
>>>>�The all-new My Yahoo! - What will yours do?
>>>>�http://my.yahoo.com
>>>>
>>>>�--------------------------------------------------------------
>>>>�---- --- To unsubscribe, e-mail: dev-
>>>>�unsubscribe@struts.apache.org For additional commands, e-
>>>>�mail: dev-help@struts.apache.org
>>>>
>>>>
>>>�----------------------------------------------------------------
>>>�---- - To unsubscribe, e-mail: dev-
>>>�unsubscribe@struts.apache.org For additional commands, e-mail:
>>>�dev-help@struts.apache.org
>>
>>
>>�------------------------------------------------------------------
>>�--- To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org For
>>�additional commands, e-mail: dev-help@struts.apache.org
>
>
>�__________________________________
>�Do you Yahoo!?
>�The all-new My Yahoo! - Get yours free!
>�http://my.yahoo.com
>
>
>�--------------------------------------------------------------------
>�- To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org For
>�additional commands, e-mail: dev-help@struts.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Spring dreaming (was Second call: add "generic" mapped property to ActionConfig)
Posted by David Graham <gr...@yahoo.com>.
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 <hu...@apache.org> 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 <cr...@gmail.com> 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
> >>> <mr...@twdata.org> 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-
> >>>> unsubscribe@struts.apache.org For additional commands, e-
> >>>> mail: dev-help@struts.apache.org
> >>>>
> >>>>
> >>> ----------------------------------------------------------------
> >>> ----- To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >>> For additional commands, e-mail: dev-help@struts.apache.org
> >>
> >>
> >> __________________________________
> >> Do you Yahoo!?
> >> The all-new My Yahoo! - What will yours do?
> >> http://my.yahoo.com
> >>
> >> ------------------------------------------------------------------
> >> --- To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org For
> >> additional commands, e-mail: dev-help@struts.apache.org
> >>
> >
> > --------------------------------------------------------------------
> > - To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org For
> > additional commands, e-mail: dev-help@struts.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
__________________________________
Do you Yahoo!?
The all-new My Yahoo! - Get yours free!
http://my.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Spring dreaming (was Second call: add "generic" mapped property to ActionConfig)
Posted by Ted Husted <hu...@apache.org>.
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 <cr...@gmail.com> 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
>>> <mr...@twdata.org> 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-
>>>> unsubscribe@struts.apache.org For additional commands, e-
>>>> mail: dev-help@struts.apache.org
>>>>
>>>>
>>> ----------------------------------------------------------------
>>> ----- To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>> __________________________________
>> Do you Yahoo!?
>> The all-new My Yahoo! - What will yours do?
>> http://my.yahoo.com
>>
>> ------------------------------------------------------------------
>> --- To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org For
>> additional commands, e-mail: dev-help@struts.apache.org
>>
>
> --------------------------------------------------------------------
> - To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org For
> additional commands, e-mail: dev-help@struts.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Spring dreaming (was Second call: add "generic" mapped property
to ActionConfig)
Posted by Don Brown <mr...@twdata.org>.
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 <cr...@gmail.com> 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 <mr...@twdata.org> 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-unsubscribe@struts.apache.org
>>>For additional commands, e-mail: dev-help@struts.apache.org
>>>
>>>
>>>
>>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>>
>>
>
>
>
>
>__________________________________
>Do you Yahoo!?
>The all-new My Yahoo! - What will yours do?
>http://my.yahoo.com
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>For additional commands, e-mail: dev-help@struts.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Spring dreaming (was Second call: add "generic" mapped property to ActionConfig)
Posted by David Graham <gr...@yahoo.com>.
--- Craig McClanahan <cr...@gmail.com> 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 <mr...@twdata.org> 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-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
__________________________________
Do you Yahoo!?
The all-new My Yahoo! - What will yours do?
http://my.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Spring dreaming (was Second call: add "generic" mapped property to ActionConfig)
Posted by Craig McClanahan <cr...@gmail.com>.
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 <mr...@twdata.org> 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-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Spring dreaming (was Second call: add "generic" mapped property to
ActionConfig)
Posted by Don Brown <mr...@twdata.org>.
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-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org