> -----Original Message-----
> From: Ted Husted [mailto:[EMAIL PROTECTED]
> Sent: 04 June 2003 12:05
> 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).
>
Right
You can dismantle the signature and create a `ProcessorContext'
class ProcessorContext {
HttpServletRequest request;
ActionMapping mapping;
...
HttpServletRequest getRequest();
ActionMapping getMapping();
...
}
class RoleProcessor extends GenericProcessor {
void processRole( ProcessorContext c) { ... }
}
class IncludeProcessor extends GenericProcessor {
void doInclude( ProcessorContext c ){ ... }
}
This could work well. How does this processor pattern
solve the problem where the RequestProcessor stores
data member? E.g. The list of Actions recorded against
a ModuleConfig.
> 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.
If you look at the Tiles source code, then you can see there
are calling initialisation methods. SHould these be also
`processified'?
> 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.
>
One question. Is a `ProcessManager' a ``RequestProcessor''?
What you have described is a sort of master delegation pattern.
Where you already have a plug-in architecture as before
in Struts 1.1 a `RequestProcessor'.
Now you want to extend into a manager interface with the
possibility to delegate methods to other objects.
If this is what you are saying this may solve the issues.
I think Matthias touched on the problem that the TilesRequestProcessor
was doing. If it was checking that the RP was subclass or assignable
against itself. If it was not it would throw an exception.
Can a subprocessor check itself for compatiblity as the Tiles RP does?
> 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.
--
Peter Pilgrim,
Struts/J2EE Consultant, RBoS FM, Risk IT
Tel: +44 (0)207-375-4923
***********************************************************************
Visit our Internet site at http://www.rbsmarkets.com
This e-mail is intended only for the addressee named above.
As this e-mail may contain confidential or privileged information,
if you are not the named addressee, you are not authorised to
retain, read, copy or disseminate this message or any part of it.
The Royal Bank of Scotland plc is registered in Scotland No 90312
Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB
Regulated by the Financial Services Authority
***********************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
