Formed like the validation, the default request chain looks like this:
process="processLocale,processContent,processNoCache,processPreprocess,processMapping,processRoles,processActionForm,processPopulate,processValidate,processForward,processInclude,processActionCreate,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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]