Sylvain Wallez wrote: ...
Secondly, we have to define means for handle-errors to be used on internal requests (i.e. SitemapSource). And in that case, as you outlined, this can be determined by the caller (the place where the "cocoon:" occurs) or in the callee (the called pipeline).
- by the caller, I don't see any other way than using an additional parameter as you proposed above. But instead of "cocoon:forward", naming it "cocoon:handle-errors" seems more adequate.
Do you mean request parameter here? I'd prefer not to pollute request parameters with internal cocoon stuff. This reminds me of recently fixed header action which was iterating over sitemap parameters. Similarly, users may rely in theirs code on request parameters and iterate over them. Adding cocoon's internal stuff as request parameters will break this. And same may happen with source cache URIs discussed recently...
- by the callee, this can be done using an additional attribute on the error-handler. What comes to mind is <map:handle-errors requests="external|internal|all">
+1. This one is nice idea. When we discussed this with Carsten last time, I came up only with pipeline parameter. Adding this parameter on handle-errors element makes more sense.
As an alternative to "requests" attribute, I can suggest "process".
Vadim
