Mailing-List: contact struts-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Struts Developers List" <struts-dev@jakarta.apache.org>
From: =?iso-8859-1?q?Kent=20S=F8lvsten=20Rasmussen?= <kent@aarhusmail.dk>
To: Struts Developers List <struts-dev@jakarta.apache.org>
Subject: Re:  Re: composable RequestProcessor
Date: Wed, 04 Jun 2003 17:18:33 +0200
MIME-Version: 1.0
References: <a0600120bbafad6d7107b@[10.0.2.2]> <3EDDD256.5040400@apache.org>
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=iso-8859-1
Message-Id: <20030604151850.BFBP24331.fepW.post.tele.dk@localhost.localdomain>

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 validatio=
ns "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 migh=
t be possible to declare that processYYY from extension XXX depends on proc=
essZZZ.

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=20
> than processing a "validation" request.
>=20
> Formed like the validation, the default request chain looks
> like this:
>=20
> process=3D"processLocale,processContent,processNoCache,process
> Preprocess,processMapping,processRoles,processActionForm,pro
> cessPopulate,processValidate,processForward,processInclude,p
> rocessActionCreate,processActionPerform,processForwardConfig
> "
>=20
> where each of these have been defined as a Subprocessor
> (e.g. Validator).
>=20
> As it stands, many of the process methods take different
> signatures and=20
> return different objects. But that could be changed so that
> they pass=20
> around a single data transfer object with a place for all
> the usual=20
> objects (request,response,mapping,form,action,forward).
>=20
> Whether each component in this sequence is systemically
> compatible or=20
> whether the order of the processes makes sense, would be the
> developer's=20
> responsibility, just as it is for defining a chain of
> Validators.
>=20
> Right now, the framework describes a lockstep lifecycle. But
> that really=20
> isn't the framework's job. The framework should provide a
> pre configured=20
> default lifecycle, but the developer should as much freedom
> as possible=20
> to define whatever lifecycle works best for a given
> application.
>=20
> The distribution could ship with a library of Subprocessors
> (just as we=20
> ship with a library of Validators). To use Tiles, you would
> make the=20
> appropriate changes to the "process" property to load the
> Tiles=20
> Subprocessors. If someone wanted to handle a different
> extension point=20
> differently (or insert a new one), they could add a
> Subprocessor to the=20
> library (as we can with validators), and amend the "process"
> property.
>=20
> So there would be no pre-ordained processABC and processXYZ
> methods or=20
> call sequence. The processor would call each process in turn
> until=20
> someone cried stop or the sequence was complete. You could
> put as many=20
> or as few Subprocessors into the sequence as you liked, same
> as we can=20
> do with Validators.
>=20
> A radical extension, like Tiles, may also need to subclass
> the main=20
> "Processor" (aka the "RequestProcessor") that would call the
> individual=20
> Subprocessors, but hopefully the methods that it overrides
> (like=20
> internalModuleRelativeForward) won't matter to the other
> Subprocessors.
>=20
> Or, maybe if Tiles does not have to live within a lockstep
> lifecycle,=20
> there might be a better way of interpolating the
> "processTiles" step, so=20
> that it doesn't need override "internal" methods.
>=20
> So, anyway, the idea is that there would be a Subprocessor
> interface and=20
> concrete implementations for each of the existing process
> methods (as=20
> individual classes). The existing RequestProcessor(s) could
> implement a=20
> Processor interface. The new ProcessManager could also
> implement the=20
> Processor interface but call individual Subprocessors from
> within the=20
> process method. (You might be even be able to do a concept
> test with a=20
> RequestProcessor subclass that called inner classes based on
> the=20
> existing processes.) Which Subprocessors the ProcessManager
> calls in=20
> what order would be configurable.
>=20
> While not as simple as what we have now, it would be more
> extensible,=20
> and has the virtue of using the same implementation pattern
> as another=20
> Struts component, the Validator. Which also means that
> ProcessManager=20
> would not be any more difficult for developers to configure
> and use than=20
> the Validator.
>=20
> -Ted.
>=20
>=20
>=20
> ------------------------------------------------------------
> ---------
> To unsubscribe, e-mail:
> struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> struts-dev-help@jakarta.apache.org
>=20


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