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 [mailto:[EMAIL PROTECTED] > 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
