On Sat, 10 Nov 2001, Luca Morandini wrote: > Giacomo, > > here's the sample: > > 1) The user goes to login.xml URI > 2) A pipeline takes care of producing the proper HTML form > 3) The user fills the form and activates "submit" > 4) The "submit" event triggers a check-login.xml being requested > 5) A pipeline takes care of calling SQLTransformer to check login/password > via a stored procedure. > 6) The SQLTransformer emits an <sql:loginStatus> element which contains the > value of an output parameter of the stored procedure, which may be "0" > (login accepted), or "not 0" (login denied) > 7) An XSL grabs the SQLTransformer's output and produces something like: > <control:status value="0" message="Login accepted"/> or > <control:status value="3" message="Wrong password"/> > 8) I'd like to call another Transformer (let's call it ControlTransformer) > which scans the output of previous step and sets a *sitemap parameter* > called "status" to match the contents of "value" attribute in > <control:status> element > 9) In the sitemap, using a ParameterSelector, the appropriate > map:redirect-to-uri is chosen, depending on the value of "status" > > I know this may be done using XSP and/or actions, but I'd like to stick to > XML/XSL as much as I can, hence avoiding XSP and actions, though I'm open to > suggestions. > > Regarding the use of the *sitemap parameter* term... I'm confised, since > in: > http://xml.apache.org/cocoon2/userdocs/selectors/selectors.html > > The following sentence is reported: "ParameterSelector: matches the string > specified in the "test" parameter against a specified Cocoon internal (e.g. > sitemap) parameter;". > > Hence, I supposed the term "sitemap parameter" was widely used. I guess > "session parameter" should be used instead, am I right ?
Exactly. Look, there are two steps in the sitemap process: 1. step: evaluation. 2. step: production. In the 1. step the sitemap assembles the components (generator, transformer and serializer) to produce the requested resource. This is done using actions, matchers and selectors. This means that the later components are activated immediately when encountered during the sitemap scan whereas the former components are activated when the pipeline is complete (read has a generator, 0-n transformer and a serializer). This implies that a selector or matcher or action cannot inspect the SAX stream the pipeline produces because the production of the SAX stream is delayed after the evaluation process. In your case you should probably stick with request/session attribute to come along what you are trying to solve. Sitemap parameter are values proposed to be configuration data passed to the components. These values could be produced by actions or matchers and passed to pipeline components (generators, transformers or serializers) but not the other way around. Hope this makes it clearer. Cheers Giacomo > > Thanks for your kind reply, > > --------------------------------------------- > Luca Morandini > GIS Consultant > [EMAIL PROTECTED] > http://utenti.tripod.it/lmorandini/index.html > --------------------------------------------- > > > > -----Original Message----- > > From: giacomo [mailto:[EMAIL PROTECTED]] > > Sent: Saturday, November 10, 2001 2:12 PM > > To: Cocoon-users; [EMAIL PROTECTED] > > Subject: Re: Sitemap parameters set by Transformer > > > > > > On Sat, 10 Nov 2001, Luca Morandini wrote: > > > > > Folks, > > > > > > does anyone know how to set a sitemap parameter from within > > a Transformer ? > > > > Why would your Transformer need to set a sitemap parameter (BTW what do > > you mean by "sitemap parameter"??) Actually there is no way (and no > > intention) to set any parameter (except those available from the > > Environment like Request, Session) > > > > > I'd like to be able to steer the sitemap flow from a > > Transformer, and the > > > best way seems to me the ability to set sitemap parameters (to > > be used in > > > some subsequent <map:select> statements). > > > > You should make a sample. > > > > Giacomo > > > > > > --------------------------------------------------------------------- Please check that your question has not already been answered in the FAQ before posting. <http://xml.apache.org/cocoon/faqs.html> To unsubscribe, e-mail: <[EMAIL PROTECTED]> For additional commands, e-mail: <[EMAIL PROTECTED]>
