cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Per Kreipke" <...@onclave.com>
Subject RE: Parameters, their stack and cocoon: protocol....
Date Tue, 18 Jun 2002 15:05:35 GMT
> > > > - If I call another pipeline with an XSP file using the cocoon:
> > > > protocol, it
> > > > doesn't seem as if the caller's sitemap parameters are available
> > > > to any XSP
> > >
> > > _sitemap_ parameters are not available to _any_ XSP. Only parameters
> > > declared _on_ generator/transformer/action/matcher/selector are
> > > available to the component.
> >
> > Fine, you're saying that "sitemap parameters" are different than the
>
> "Sitemap parameters" which are available for substitution as {1},
> {name}, {../other}, etc, *are* different from the <map:parameter/>s on
> components.
>
> "Sitemap parameters" is a Stack of Maps, and every matcher/action adds
> one more Map to it, and it is removed as soon as matcher/action tag is
> closed. To navigate the stack, you have directory-like {../../1} syntax.

Ok. Got it.

> > map:parameters that are declared on gen/trans/action/match/select
> sections.
> >
> > Then let me ask: are the caller's parameters available to the callee
> below?
> >
> > > > the called pipeline. Is that true? E.g.
> > > >
> > > >   <!-- Callee -->
> > > >   <map:match pattern="config">
> > > >      <map:generate src="config.xsp" />
> > > >      <map:serialize type="xml" />
> > > >   </map:match>
> > > >
> > > >   <!-- Caller -->
> > > >   <map:match pattern="*/foo">
> > > >     <map:generate src="cocoon:/config>
> > > >       <map:parameter name="client" value="{2}" />
> > >
> > > Does this syntax exist? (too lazy to check source code...)
> >
> > First, should have been {1}.
> > Second, what syntax do you mean?
>
> Sorry, did not get at first.
>
> Parameter declared on the generator will be available *only* to this
> generator. What generator will do with it - it's a different question.

Ah. So they won't be available to the generator in the other matcher. Ok.

> In this particular case, this parameter will be used nowhere.

Well, I was hoping that the config.xsp would have it to do something with.
For example, the sitemap fragment for "config" could be used from different
parts of the sitemap with different values (e.g. different clients, etc).

I see your examples below for another way to do it. Will check them out,
thanks.

> > > >     </map:generate>
> > > >   </map:match>
> > > >
> > > > in config.xsp, I can't get the value of {client} through
> > > > parameters.getParameter("client").
> >
> > > > - corollary: is the stack of parameters available to XSP file?
> > >
> > > No.
> >
> > Sigh.
>
> "Sitemap parameters", this stack of maps, will not exist once execution
> of sitemap is finished. And execution of XSP will not start before
> execution of sitemap is finished.

Now that's very interesting and important. I did not know that. Will remap
my synapses right away.

> > > > Or is there a
> > > > way of getting the parent of the parameters?
> > >
> > > Sorry, did not get this one.
> >
> > Can I (from XSP) ask for parameters.getParameter("../../client") for
> > example?
>
> No. You can ask only for parameters which are declared on XSP.

Right, got it now.

> Example 1:
>
> <!-- Callee -->
> <map:match pattern="config">
>   <map:match type="reqest-parameter" pattern="client">
>     <map:generate src="config.xsp">
>       <map:parameter name="client" value="{1}"/>
>     </map:generate>
>   <map:serialize type="xml" />
> </map:match>
>
> <!-- Caller -->
> <map:match pattern="*/foo">
>   <map:generate src="cocoon:/config?client={1}"/>
>   <map:serialize type="xml" />
> </map:match>
>
>
> Example 2:
>
> <!-- Callee -->
> <map:match pattern="config/*">
>   <map:generate src="config.xsp">
>     <map:parameter name="client" value="{1}"/>
>   </map:generate>
> </map:match>
>
> <!-- Caller -->
> <map:match pattern="*/foo">
>   <map:generate src="cocoon:/config/{1}"/>
>   <map:serialize type="xml" />
> </map:match>

Thanks much. I'd done the same for another pipeline. Not sure why I didn't
think of it for this part :-)

Per


---------------------------------------------------------------------
Please check that your question  has not already been answered in the
FAQ before posting.     <http://xml.apache.org/cocoon/faq/index.html>

To unsubscribe, e-mail:     <cocoon-users-unsubscribe@xml.apache.org>
For additional commands, e-mail:   <cocoon-users-help@xml.apache.org>


Mime
View raw message