On 03.Dec.2001 -- 05:51 PM, Sylvain Wallez wrote:
>
> Stefano Mazzocchi a écrit :
> >
> > Christian Haul wrote:
> > >
> > > There's no language element that allows setting of sitemap parameters
> > > er, variables. They are usually the result of sitemap components
> > > execution. More in particular, from those components that are used to
> > > determine the actual pipeline from the given fragments (matchers,
> > > actions; selectors return only true / false).
> > >
> > > When using <map:resources/> to hold common parts of pipelines, it is
> > > often desirable that they depend on some values determined further up
> > > the pipeline.
> > >
> > > Often, an action or matcher already exists, that has the functionality
> > > required, but additional parameters need to be set for the processing
> > > in a resource. <map:parameter/> is used to do runtime configuration of
> > > components. <map:redirect-to/> is no component but a control statement
> > > and thus doesn't take runtime configuration.
> > >
> > > Thus the only solution today is, to modify an existing component to
> > > set additional parameters, or to write a custom action that just sets
> > > some parameters.
> > >
> > > <map:redirect-to resource=""/> does have @target which is probably not
> > > as clean as possible. A better solution would be, to introduce some
> > > construct to set those variables without the need of an action, like
> > >
> > > <map:variables>
> > > <map:parameter name="foo" value="xyz"/>
> > > <map:parameter name="bar" value="uvw"/>
> > > </map:variables>
> > >
> >
> > I like the concept and I agree it's useful.
> >
> > But instead of modifying existing behavior, why don't we come with
> > another element
> >
> > <map:call resource="">
> >
> > That would also take care of composing pipeline verbosity (something
> > that Berin proposed a while back placing pipelines (here resources) into
> > different files.
>
> Why is a new "map:variable" needed ? As for now, map:redirect doesn't
> have parameters, but we could define the semantic for parameters of
> map:redirect as sitemap parameters that are set prior to calling the
> resource. This would lead to the following :
> <map:redirect-to resource="HTML page">
> <map:parameter name="source" value="{1}"/>
> <map:parameter name="stylesheet" value="page2html.xsl"/>
> </map:redirect-to>
>
> So -1 for map:variable : we should extend the use of the existing
> map:parameter feature to map:redirect.
>
> Now could you please explain "map:call" ? Is it to replace
> "map:redirect-to" for resources ? I admit I don't like much handling
> calls to resources and external redirects using a single primitive :
> redirecting to a resource continues the building of the current pipeline
> by jumping somewhere else in the sitemap (and map:call is a good name
> for this), while redirecting to an external URI has the effect of
> clearing the current pipeline through a hop to the client browser.
I second this opinion.
So shall we have
<map:call resource="foo">
<map:parameter name="bar" value="xyz"/>
</map:call>
and deprecate <map:redirect-to resource=""/> ?
Although it breaks the current rule, that only components do have parameters.
> There's also a need to perform internal redirects, or forwards in
> servlet parlance : a redirect that clears the current pipeline, but
> doesn't go back to the browser, in order to keep the current context
> (request, object model, etc). Someone (Carsten ?) once proposed to use
> the special "cocoon:" protocol for this. What about that ?
Another thought would be to remove resources altogether and have such
internal forwards, with and without keeping current context. After we
introduced "internal" pipelines there's probably not much need for
"resources" anymore if such forwarding would be in place and it would
take parameters as discussed for <map:call/>.
Chris.
--
C h r i s t i a n H a u l
[EMAIL PROTECTED]
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
