On Sun, 11 Nov 2001, Luca Morandini wrote: > Giacomo, > > thanks for explaining to me the whole sitemap parameters concept. > > Though... why an action or a matcher can set, say, a session parameter, and > a transformer cannot ?
No, both are able to set session attributes. But the time line WHEN they do it is different. When a transformer sets a session attribute during its scan of the SAX events pased throught it there is not chance for a Selector to cach it up. The execution time scope of actions, matchers and selectors are different from generators, transformers and serializers. First only actions, matchers and selectors are executed (to asseble the pipeline) afterwards only generators, transformers and serializers are executed (plugged together to form the pipeline and process SAX events). Hope it is another step forward to make it clearer. Giacomo > > I mean, there is a compelling rason for it... or it could be done but the > developers deemed it to be unnecessary (as it probably is) ? > > Best regards, > > --------------------------------------------- > Luca Morandini > GIS Consultant > [EMAIL PROTECTED] > http://utenti.tripod.it/lmorandini/index.html > --------------------------------------------- > > > > -----Original Message----- > > From: giacomo [mailto:[EMAIL PROTECTED]] > > Sent: Sunday, November 11, 2001 11:41 AM > > To: [EMAIL PROTECTED] > > Subject: RE: Sitemap parameters set by Transformer > > > > > > 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]> > > > > --------------------------------------------------------------------- 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]>
