3) +1 on keeping the existing IoC framework. It's simple
but that's its allure. I personally don't want to have do introduce another
dependency into my apps just to do the simple IoC type things I do
now.
4) I'd recommend leaving an open design, with a simple
implementation (like now), with the option to replace the guts with the
framework of choice. Put the burden of implementation on the framework
supporters. Again, I don't want another dependency if I don't need one, and I
don't need one now. I'd support only enough refactoring to allow for different
components to be replaced as needed. I'm against redesigning everything just to
deal with IoC containers that people may or may not be interested
in.
Bottom line: Xwork is simple, and it should stay that way.
Some refactoring is good if it lets people switch out parts and replace them
with what they need, but more than that is probably unnecessary and
undesirable.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jason Carreira
Sent: Monday, February 23, 2004 6:09 PM
To: [EMAIL PROTECTED]
Subject: [OS-webwork] ObjectFactory / XWork internals refactoring
Several people have
been asking about replacing the clazz.newInstance() calls in XWork with object
factories which can be replaced, to allow integration with Spring/Pico/etc...
While I'm all for this, I think there are some issues that need to be thought
through so we can get a design that really works and meets everyone's
needs...
1) Lifecycle / Scope
: Some object instances, like Actions, are request scoped, and can depend on
request scoped components. Some, like Interceptors, can only depend on
application scoped components. I can't think of any that are session scoped
right now...
2) The internals of
XWork are filled with static singletons which can be replaced at system
initialization... Should we tackle replacing these with making all of the
internal components of XWork be wired together by the object factory at
runtime?
3) XWork IoC... How
much do we want to put into this? Should we deprecate this in favor of an
integration with a dedicated IoC container?
4) IoC container
support: Do we want to create a generic Interface for these integrations, and
provide different implementations, or do we want to choose one and make it the
heart of the framework, such that it weaves together all of the other pieces,
which become components (which Actions, Interceptors, Results, etc could depend
on)? Or, do we want to do this 2+ times, defining the dependencies and letting
either Spring or Pico, etc. pull it together at runtime? This is dependent on
#2, obviously...
One question I had
about these frameworks... Is it possible for me to define a default
configuration, and allow the users of the framework to just selectively replace
individual components, or would they have to reconfigure the whole thing?
Thoughts? Ideas?
Jason
