Sylvain Wallez wrote:
Carsten Ziegeler wrote:
As discussed recently, our internal redirects don't work the way one
would usually suspect. If you do an internal
redirect, like:
map:redirect-to uri=cocoon://some-pipeline/
and the called pipeline has an error, then the error handler
of the
Vadim Gritsenko wrote:
So, we have three choices to change this:
a) Make an internal redirect a real forward (This is an
incompatible change)
b) Make it configurable on the uri, like map:redirect-to
uri=cocoon://some-pipeline?cocoon:forward=true/
c) Make it configurable on
Vadim Gritsenko wrote:
snip/
Why (a), (b), or (c) ? There is always option of (d):
d) Make it configurable on handle-errors element of the called
pipeline. This way, behavior of redirect-to does not need to be
changed, and this feature is more useful in general - especially in
portlets. Or
Do real forwards have the ability to stay within the same sitemap? I'm
assuming this method would call the RequestDispatcher's forward method? If
so, would this finally allow constructs such as map:redirect-to
uri=cocoon:/../parent-pipeline ? This would seem logical as you'd have
to construct
On 10.03.2004 16:20, Carsten Ziegeler wrote:
a) Make an internal redirect a real forward (This is an
incompatible change)
+1 This is indeed what I expect!
Joerg
Sylvain Wallez wrote:
Carsten Ziegeler wrote:
As discussed recently, our internal redirects don't work the way one
would usually suspect. If you do an internal
redirect, like:
map:redirect-to uri=cocoon://some-pipeline/
and the called pipeline has an error, then the error handler
of the
