Joe Germuska wrote:
<snip />
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.
Sure, sounds like a good approach; I'll look into it. I'm pretty new to Spring and haven't used multiple factories
much. I'm open to using Spring to create chain commands, as long as the configuration file is separate from the rest of
Spring services.
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.
My concerns there are YAC (Yet another context), and how will it play with XWork, which has its own way to handle
message resources? Using multiple projects is fine as long as we can smooth out duplications for the user.
Don
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
