struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Robertson <>
Subject RE: composable RequestProcessor
Date Wed, 04 Jun 2003 13:47:04 GMT
Wow. Mr. Husted, this may seem like an obvious conclusion to you, but to me
(and probably others as well) this is a big "hey, why didn't I think of
that!" moment.

> -----Original Message-----
> From: Ted Husted []
> Sent: Wednesday, June 04, 2003 7:05 AM
> To: Struts Developers List
> Subject: Re: composable RequestProcessor
> I still don't see why processing an "action" request is any different 
> than processing a "validation" request.
> Formed like the validation, the default request chain looks like this:
> process="processLocale,processContent,processNoCache,processPr
> eprocess,processMapping,processRoles,processActionForm,process
> Populate,processValidate,processForward,processInclude,process
> ActionCreate,processActionPerform,processForwardConfig"
> where each of these have been defined as a Subprocessor (e.g. 
> Validator).
> As it stands, many of the process methods take different 
> signatures and 
> return different objects. But that could be changed so that they pass 
> around a single data transfer object with a place for all the usual 
> objects (request,response,mapping,form,action,forward).
> Whether each component in this sequence is systemically compatible or 
> whether the order of the processes makes sense, would be the 
> developer's 
> responsibility, just as it is for defining a chain of Validators.
> Right now, the framework describes a lockstep lifecycle. But 
> that really 
> isn't the framework's job. The framework should provide a pre 
> configured 
> default lifecycle, but the developer should as much freedom 
> as possible 
> to define whatever lifecycle works best for a given application.
> The distribution could ship with a library of Subprocessors 
> (just as we 
> ship with a library of Validators). To use Tiles, you would make the 
> appropriate changes to the "process" property to load the Tiles 
> Subprocessors. If someone wanted to handle a different 
> extension point 
> differently (or insert a new one), they could add a 
> Subprocessor to the 
> library (as we can with validators), and amend the "process" property.
> So there would be no pre-ordained processABC and processXYZ 
> methods or 
> call sequence. The processor would call each process in turn until 
> someone cried stop or the sequence was complete. You could 
> put as many 
> or as few Subprocessors into the sequence as you liked, same 
> as we can 
> do with Validators.
> A radical extension, like Tiles, may also need to subclass the main 
> "Processor" (aka the "RequestProcessor") that would call the 
> individual 
> Subprocessors, but hopefully the methods that it overrides (like 
> internalModuleRelativeForward) won't matter to the other 
> Subprocessors.
> Or, maybe if Tiles does not have to live within a lockstep lifecycle, 
> there might be a better way of interpolating the 
> "processTiles" step, so 
> that it doesn't need override "internal" methods.
> So, anyway, the idea is that there would be a Subprocessor 
> interface and 
> concrete implementations for each of the existing process methods (as 
> individual classes). The existing RequestProcessor(s) could 
> implement a 
> Processor interface. The new ProcessManager could also implement the 
> Processor interface but call individual Subprocessors from within the 
> process method. (You might be even be able to do a concept 
> test with a 
> RequestProcessor subclass that called inner classes based on the 
> existing processes.) Which Subprocessors the ProcessManager calls in 
> what order would be configurable.
> While not as simple as what we have now, it would be more extensible, 
> and has the virtue of using the same implementation pattern 
> as another 
> Struts component, the Validator. Which also means that ProcessManager 
> would not be any more difficult for developers to configure 
> and use than 
> the Validator.
> -Ted.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message