cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylvain.wal...@anyware-tech.com>
Subject Re: [VOTE] directly setting variables in sitemap
Date Tue, 04 Dec 2001 09:30:26 GMT


Christian Haul a écrit :
> 
> 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.

I wasn't aware of this rule...

> > 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.

Mmmh... Resources are IMO really different from redirects and both are
needed :

- resources are common sitemap constructs that can be reused in
pipelines. It helps reduce the verbosity by factorization. In that
sense, they're like methods in Java code. That's why map:call is
appropriate, because this is really a jump to a named pipeline snippet.

- redirects OTH clear the current pipeline, either by a hop to the
client browser (external redirect, meaning a new request) or by a
recursive call of the sitemap engine (internal redirect). In both kinds
of redirects you have to go again through the pipeline selection process
(map:match).

Sylvain

-- 
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message