At 10:10 AM -0700 8/31/05, Don Brown wrote:
Hmm...I like the idea of combining the configurations from a
maintenance point of view, but on the other hand, the flow chain can
get lost, particularly when the number of commands are in a
minority. Separating also has the benefit, in our case anyways, of
having the chain stay generic, but Spring providing implementations
specific to an environment.
So I'm just now starting to poke around Ti (see what all this chatter
can do?)...
I've just recently started getting my head around Spring's approach
to nested BeanFactories (or ApplicationContexts) and I'm wondering if
that isn't a better bootstrap mechanism than the explicit
instantiation of an XmlBeanFactory. It seems more likely to support
a mixture of struts-specified along with user-specified configuration
with a minimum of headache. (The most documentation I've found about
this concept is at
http://www.springframework.org/docs/api/org/springframework/beans/factory/access/SingletonBeanFactoryLocator.html)
If Struts Ti used this with a servlet init parameter whose name was
the root BeanFactory, then a user could add his own
beanRefFactory.xml file in /WEB-INF/classes and create a child
BeanFactory which had full access to the Struts factory as well as
its own options, including potentially defining alternative
implementations under well-known bean names.
This also makes it fairly trivial to break out Struts' own XML
configuration into multiple files, so that there could be a
"chain-config.xml" file which adhered to the spring-beans.dtd instead
of using Digester.
Don't get me wrong, Digester helped me to a heck of a lot on projects
over the last few years, but I am not sure I see it as playing very
well with Spring, and for most cases (like bootstrap config, at
least), there's nothing it can do that Spring's XML can't do.
On a similar subject, were BeanFactories chosen over
ApplicationContexts specifically? It seems like ApplicationContext
would buy a bunch of simplicity (like unifying access around the
ApplicationContext as the default MessageSource for all
internationalization) at the cost of only another 100 k JAR
dependency.
Joe
Still, one less file is always a good thing as well. I wonder what
it would look like if you customized the XML file format a bit.
Didn't James Strachan do something like that with one of his
projects?
Don
Ted Husted wrote:
On 8/31/05, Don Brown <[EMAIL PROTECTED]> wrote:
You might also be interested in the Spring and Chain integration
piece I wrote for Ti.
We just load the Commands and Chains with Spring, along with
everything else, and don't bother with a separate catalog.
It started out ugly, but if you make good use of the parent
features, things end up pretty clean, and there's only one DI
syntax.
<object id="BaseChain" type="WQD.Core.Commands.BaseChain, WQD.Core"
parent="BaseLogic"/>
... later ...
<object id="facility_edit" parent="BaseChain">
<property name="AddCommands">
<list>
<ref object="facility_select" />
<ref object="facility_find" />
</list>
</property>
</object>
We had to extend the original CoR API a bit, so that we could add a
list of commands to a chian.
This is from a C# application, but you see what is happening.
We also do things like create base data-access commands that know
how to run iBATIS
-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
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
