Konstantin Piroumian wrote:
>>From: Ivelin Ivanov [mailto:[EMAIL PROTECTED]]
>>
>>+1
>>
>>
>>I'm also a bit confused by the cocoon:
>>proto. Isn't there more to it than just forward?
>>
Nothing more !
>>The parameters to forward are request attributes correct?
>>You can't add request parameters with server side forward.
>>
>
>I've been thinking about them as sitemap parameters, but I'm not sure that
>it's possible to implement in current sitemap and also it will cause
>unexpected behavior in request parameter-aware pipelines. But definitely,
>they are not request attributes. You can't add parameters, but you can call
>an URL with new parameters: 'show-page.xml?page=success'.
>
>Is it possible with the current sitemap implementations?
>
As I said before, a forward using the "cocoon:" protocol is a new
request on the Processor component (i.e. the sitemap). So there's no
transmission of sitemap variables, and this fact is not tied to a
particular implementation of the sitemap.
The new request is built with the redirect URI, and its parameters are
defined by (in precedence order) :
- parameters in the URI, i.e. "path?param=value"
- parameters "inherited" from the original request. If you don't want to
inherit these, the "cocoon:raw" protocol should be used.
The <map:parameters> in a <map:forward> should go as new parameters for
this request and thus writing :
<map:forward uri="page">
<map:param name="foo" value="{1}"/>
</map:forward>
is equivalent to writing
<map:forward uri="page?foo={1}"/>
or even
<map:redirect-to uri="cocoon:/page?foo={1}"/>
But we see here that this creates a multipath. I'm still +1 for
<map:forward> to distinguish internal/external redirects, but -0 for
<map:parameters> inside a forward...
Sylvain
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
