struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Hill" <>
Subject RE: composable RequestProcessor
Date Mon, 02 Jun 2003 12:53:48 GMT
At this point, I think the main goal is to come up with a decent name
for an interface which RequestProcessor could implement

How about "IRequestProcessor"?????

(Yeh, okay so Im of the "every interface should start with an 'I' or the
writer should die!" school of thought, as well as the even more diabolical
school that thinks "absabludylootly everything should be accessed through an
interface". ;->)

-----Original Message-----
From: Joe Germuska []
Sent: Monday, 2 June 2003 20:42
To: Struts Developers List
Subject: Re: composable RequestProcessor

>Let's take a back step, then. What is a composable request processor?
>What is the thing that you are trying to build?
>MasterRequestProcessor master = new MasterRequestProcessor();
>master.add( TilesRequestProcessor );
>master.add( FoobarRquestProcessor );

Actually, it would be more like:

master.add(FORWARD_CONFIG, TilesRequestProcessor.class);
master.add(PREPROCESS, ExpressoRequestProcessor.class);

Where the first arguments are some kind of constant referring to the
lifecycle phase which is to be handled, and the second to a class
whose implementation of that lifecycle method you want used.  Maybe
you'd pass instances instead of classes...

Could be, except if it's not something anyone really wants, we should
probably just skip it!   The whole question arose simply because one
of my colleagues wanted to provide special processing for just
processActionForm() and she didn't want to make the decision between
extending RequestProcessor or TilesRequestProcessor.

That lead to the current discussion, which is mostly theoretical,
since no one who has spent longer extending RequestProcessor is
clamoring for this kind of complexity.  Even if they were clamoring,
no one would probably pay attention unless they put up some code to
back up the clamor.

At this point, I think the main goal is to come up with a decent name
for an interface which RequestProcessor could implement, or to put it
off until 2.0 when we might reasonably use the name
"RequestProcessor" for an interface and not be worried about
compatibility with 1.x code.

But then, if you see the value of a truly composable RequestProcessor
and write one, someone somewhere would probably be interested in it.
If you really wanted to, you could do it now by subclassing
ControllerConfig and using bean properties to set handler classes for
various lifecycle methods.


Joe Germuska
"If nature worked that way, the universe would crash all the time."
	--Jaron Lanier

To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message