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]
