Like targets in Ant... -----Original Message----- From: Kent Sølvsten Rasmussen [mailto:[EMAIL PROTECTED] Sent: Wednesday, 4 June 2003 23:19 To: Struts Developers List Subject: Re: Re: composable RequestProcessor
Just a thought... Would it be possible to take the anology to Validator one step further? Instead of a predefined or configurable lifecycle, would it be possible to let the SubProcessors depend on each other, just like some of the validations "depend" on each other? Maybe the configurationfile could contain a number of named subprocessors, some default, some from Tiles, some from other extensions. This way it might be possible to declare that processYYY from extension XXX depends on processZZZ. This way a chain might be defined, not by defining the chain itself, but by defining dependencies among it's subprocessors. Sorry for being unclear, but hopefully You get the idea. -Kent Ted Husted <[EMAIL PROTECTED]> wrote: > 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,process > Preprocess,processMapping,processRoles,processActionForm,pro > cessPopulate,processValidate,processForward,processInclude,p > rocessActionCreate,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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
