struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brandon Goodin" <m...@phase.ws>
Subject RE: Re: composable RequestProcessor
Date Wed, 04 Jun 2003 15:36:04 GMT
That sounds very complex. With Validator we are dealing with quantifiable
results. This is not so cut and dry with RP stuff. With the RP I think we
would do best not to add anymore complexity than neccessary. One process
should be ignorant of the other unless data is provided in the Tranfer
Object to trigger certain behavior of functionality. Can you think of an
example where this would be neccessary? If your extension has dependencies
on another extension, I think it would be best to just document it.

Brandon Goodin

-----Original Message-----
From: Kent SĂžlvsten Rasmussen [mailto:kent@aarhusmail.dk]
Sent: Wednesday, June 04, 2003 9:19 AM
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 <husted@apache.org> 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:
> struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> struts-dev-help@jakarta.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org


Mime
View raw message