Hi, Don,

I'm thinking out loud here.  

I have been chewing on this because I am in a mode where I have to
think about where to put my energies the next few years.  So, I might
as well jump in here and see what people think.  At least I know
enough to listen.

I like what Vic was saying about CoR and IoC, by the way.  

Inversion of control is merely that: inversion of control.  You pass
control of some choice or process over to the framework.  As such, IoC
is really so general as to be less than really helpful on any
particulars, even where the term "IoC" is an accurate description of
what is going on.  That is why Martin Fowler uses Dependency Injection
instead of IoC in his well-known piece on the same.

When you have a "helper" interface, e.g. Fowler's MovieFinder
interface, and you want to be able to use different implementations in
a framework, Fowler calls that Dependency Injection.  Essentially,
this allows you to use the same code internally while passing the name
or type of the object which implements the interface to some assembly
mechanism in the container.

Sometimes you want to do this, viz. have the choice of using multiple
implementations and having the container assembled with your choice,
usually using configuration xml and some equivalent of Pico's
NanoContainer to manage the xml assembly.  Or, you can use a Service
Locator to do the same thing.  Where you just want to use one
implementation, I prefer using or at least am considering prefering
using hot deploy.  This means that you don't have to use IoC or
Service Locator or anything else to have differing implementations in
the same framework.  What is more, not only are there, as Craig
McClanahan says, "fewer moving parts", but also you can choose to
employ differing implementations of the same interface with different
names (think Action subclasses) and each of these can then be hot
deployed as well.  Lastly, if you are using CoR you can also use hot
deploy to allow varying implementations.

As a result, I am starting to think that hot deploy is a better
solution than either service locator or dependency injection to the
problem of allowing differing implementations of interfaces in an
interface.  Anyone that has further thoughts on this, I would be more
than interested.

With hot deploy, instead of switching the implementation and the name
of the implementation class, e.g. ColonSeparatedMovieFinder for
DatabaseMovieFinder, you just have an implementation called
MovieFinderImplementation (or whatever you want, e.g. X) and a
MovieFinderImplementationHotFactory for getting object instance
implementations of the MovieFinder interfaces.  Conceivably, in fact,
you can give people differing implementations with the same name by
simply putting them in different directories: no problem.  This means
that the code can be dynamic and alterable at will and that there need
be no changes anywhere if you don't want there to be other than
dumping the new MovieFinderImplemenation.class in some directory
somewhere.

Anyway, I am starting to fall in love with this idea for the moment. 
LOL  Any experience on this out there?  I would like a way to update
objects in this sort of design without killing garbage collection by
maintaining references.  Any ideas on that?

Jack






On Wed, 24 Nov 2004 11:08:46 -0800, Don Brown <[EMAIL PROTECTED]> wrote:
> I look at technology as solutions to problems.  IoC solves the problem
> of how can I define and configure a component external to the component
> and calling code, and CoR tackles the problem of a how can I define a
> process or sequence of processes in a pluggable manner.
> 
> True, both patterns have a "pluggable" property, but both a HashMap and
> a SQL database have a "lookup" property.  I think what you are getting
> at is, in Struts, we need a way to allow the framework to be easily
> customized by both framework extension projects and users.  Both IoC and
> CoR help us meet that goal, but by solving two different problems that
> work against "pluggability".  In Struts, I see the need for allowing the
> user to have more control over the process of events, as well as what
> components are used by that process.  So yes, one goal perhaps, but two
> different problems being solved in two different ways.
> 
> Don
> 
> 
> 
> Dakota Jack wrote:
> 
> >Without disagreeing with anything you have said, Don, I think the
> >confusion is caused in part by the fact that CoR is anticipated in
> >part for its pluggable nature.  In this respect, there is a real
> >connection in functionality between CoR and IoC that is not as
> >attenuated as the one between HashMap and a SQL database but more like
> >a properties file and a SQL database?  You think?
> >
> >Jack
> >
> >
> >On Wed, 24 Nov 2004 10:44:30 -0800, Don Brown <[EMAIL PROTECTED]> wrote:
> >
> >
> >>Not you personally BaTien, I don't understand why some people seem to
> >>confuse Inversion of Control (IoC) and Chain of Responsibility (CoR),
> >>and worse, think they are somehow solving the same problem.  IoC helps
> >>us create components by managing their lifecycle and providing their
> >>dependencies.  CoR defines a process that let's us flexibly specify what
> >>code to execute in what order.
> >>
> >>Sure, commons-chain does provide the default capability to create
> >>commands and configure them with simple properties, but that isn't its
> >>purpose and would certainly be replaced in any moderately complex usage,
> >>most likely by some sort of IoC.  It's like saying a HashMap conflicts
> >>with a SQL database as they both store data.  They are two very
> >>different things with very different problems they are trying to solve.
> >>
> >>Don
> >>
> >>
> >>
> >>BaTien Duong wrote:
> >>
> >>
> >>
> >>>Craig McClanahan wrote:
> >>>
> >>>
> >>>
> >>>>On Tue, 23 Nov 2004 14:20:02 -0600, Joe Germuska <[EMAIL PROTECTED]>
> >>>>wrote:
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>
> >>>>>
> >>>>>>I need to have a hook into processValidate() on validation failure.
> >>>>>>
> >>>>>>Currently that can only be done by copy-and-pasting the
> >>>>>>processValidate()
> >>>>>>method from RequestProcessor into a subclass and sticking a hook
> >>>>>>into the
> >>>>>>middle of the code.
> >>>>>>
> >>>>>>When I asked about this on the dev list long ago, it was confirmed
> >>>>>>that
> >>>>>>there was no other way to do this, but that chain would eventually
> >>>>>>provide
> >>>>>>this flexibility.
> >>>>>>
> >>>>>>If the chain isn't configured at a fine-grain level, then it's not
> >>>>>>all that
> >>>>>>much more functional than the existing RequestProcessor.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>The chain is configured at as fine-grained a level as you like, in
> >>>>>XML.  Hubert is talking about configuring the chain programatically
> >>>>>as well, or at least in some way independent of the configuration of
> >>>>>the primary processing chain.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>Programmatic configuration is certainly feasible ... there's no
> >>>>requirement in [chain] that you use the XML format at all.  It's just
> >>>>one option.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>Greetings and request expert advice:
> >>>
> >>>Commons-chain invented by Craig proves to be very flexible and work in
> >>>conjuction with other great technonologies. What i am trying to figure
> >>>out is a proper and practical places for using CoR and IoC (such as
> >>>Spring framework) in the construction and configuration of software
> >>>objects. I put out some of my preliminary thinking and hope some
> >>>experts care to add more arguments to enlighten us.
> >>>
> >>>1) Both CoR and IoC (and also Jsf setter injection) enable the
> >>>configuration and linking objects via XML metadata. But IoC allows the
> >>>object configuration at a finer level of object attributes and take
> >>>care of the objects declared as singleton. In this sense, IoC is finer
> >>>grain than CoR in object creation, configuration and management.
> >>>
> >>>2) CoR is very light weight and appropriate for programmatically
> >>>created processes. It does not not have the complexity and the depth
> >>>of plug-in features as Spring IoC.
> >>>
> >>>3) CoR is finer grain than IoC in the construction and rounting of
> >>>services within and between software layers, while IoC is aprropriate
> >>>at the application level.
> >>>
> >>>4) If we want to combine Jsf as view controller, Spring IoC and
> >>>commons-chain CoR, a practical infrastructure may be something like
> >>>followings:
> >>>   a) Jsf as a view controller takes care of objects directly related
> >>>to User Interface (UI)
> >>>   b) Spring IoC takes the responsibility of object creation,
> >>>especially singletons and fine grain configurations of objects not
> >>>directly related to UI. This is a proper choice of configuration if
> >>>other features of Spring framework such as application level event and
> >>>aop are used.
> >>>   c) CoR is used to construct Front Controller a la pattern of Struts
> >>>of each software module, the rounting of services among modules, and
> >>>action commands (or chain) of specialized services in each service
> >>>module. It programmatically links created components from IoC to a
> >>>finer grain at each software module, which holds the module Catalog of
> >>>commands.
> >>>   d) User session is a proper place for programmatically interactions
> >>>of Jsf, IoC and CoR objects. For example user generated events from
> >>>Jsf is linked through a CoR adapter to dispatch action command as a
> >>>request to appropriate software module (such as
> >>>authentication/authorization, portlet, service, etc) whose responses
> >>>are rendered through Jsf view controller.
> >>>
> >>>BaTien
> >>>DBGROUPS
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>>>As long as you're willing to copy the base chain-config.xml file and
> >>>>>make a few modifications, then you could simply add your own command
> >>>>>which retrieves a value from the context under a well-known key and
> >>>>>inspects the value to see if validation passed or not.  This exact
> >>>>>logic is the first thing executed in the CreateAction's execute
> >>>>>method, which doesn't lookup or create an action unless the form
> >>>>>validated.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>There's actually quite a few different ways to approach this,
> >>>>including the "optionally invoke some other command at this point"
> >>>>mentioned earlier in the thread, so you don't even *have* to
> >>>>cut-n-paste the standard version of the chain.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>You can start experimenting with commons-chain and struts-chain from
> >>>>>CVS Head if you want to see what's going on.  You don't have to wait
> >>>>>for Struts 1.3.
> >>>>>
> >>>>>
> >>>>>
> >>>>Indeed, Struts-Chain directly illustrates the fine-grained approach to
> >>>>defining the standard request processing chain that Joe describes.
> >>>>Nightly builds are available at:
> >>>>
> >>>>http://cvs.apache.org/builds/jakarta-struts/nightly/struts-chain/
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>Joe
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>Craig
> >>>>
> >>>>---------------------------------------------------------------------
> >>>>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]
> >>>
> >>>
> >>>
> >>---------------------------------------------------------------------
> >>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]
> 
> 


-- 


"You can't wake a person who is pretending to be asleep."

~Native Proverb~

"Each man is good in His sight. It is not necessary for eagles to be crows."

~Hunkesni (Sitting Bull), Hunkpapa Sioux~

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to