On 8/31/05, Don Brown <[EMAIL PROTECTED]> wrote:
>
> Very interesting. Do you have any examples/tutorials of this anywhere
> accessible?
That's where the OverDrive/Nexus stuff is going, but, lately, the volunteer
hours have been going into Struts Classic :)
I'm doing some major refactoring
So, I really do have work I should be doing, but I couldn't help
looking around XWork a little bit, and I'm just wondering why Ti
needs to use both it and Spring anyway?
What are the various services offered by each that aren't offered by the other?
Joe
At 2:44 PM -0500 8/31/05, Joe Germuska
Great, I like it! The XWork messages are only for the user and not used by Ti internally at all. If using the
ApplicationContext doesn't impact the user negatively, I'm all for it.
The earliest I could make these changes would be next week, but if you are
volunteering... :)
Don
Joe Germuska
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 a
Joe Germuska wrote:
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
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 anywa
Very interesting. Do you have any examples/tutorials of this anywhere
accessible?
Don
Ted Husted wrote:
(Mouse slipped)
On 8/31/05, Ted Husted <[EMAIL PROTECTED]> wrote:
We also do things like create base data-access commands that know how to
run iBATIS
-Ted.
We also do things lik
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 Spri
