struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Germuska <...@Germuska.com>
Subject Re: composable RequestProcessor
Date Mon, 02 Jun 2003 12:41:56 GMT
>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

-- 
--
Joe Germuska            
Joe@Germuska.com  
http://blog.germuska.com    
"If nature worked that way, the universe would crash all the time." 
	--Jaron Lanier

---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org


Mime
View raw message