Yes, you can aggregate error messages. Just move the content generation with
<map:part src="cocoon:/content"/>
to another pipeline
<map:match pattern="content">
with its own error-handling. Error-handling can happen at different
levels. I use it at the <map:pipeline> level, but remember reading
about other levels. You can have multiple <map:pipeline> elements in
an XMAP, each with its own error-handling.
In my current work, the aggregated display pipeline retrieves the
content from a different XMAP. The content XMAP return error messages
in the same format as the content so the aggregation treats it as good
content. Make certain to use:
<map:serialize type="xml" status-code="404"/>
The "status-code" attribute is intercepted at the SerializeNodeBuilder
and set in SerializeNode so the attribute affects all Serializers and
you can set the http response code from any Serializer. The default
is 200; never set that because the last "status-code" attribute
encountered is used. Using a variable for the attribute requires
Cocoon-2.1.11; earlier versions did not resolve variables:
<map:serialize type="xml" status-code="{status}"/>
This is useful in a <map:resource> used for multiple errors.
(Error code 401 should be saved for actions. True security requires
not notifying people that unauthorized documents exist. The 404
message displayed should list possibilities like, "The requested
content does not exist or the current account may not have access to
it.")
The content pipeline response must be acceptable to later transforms
in your aggregations. You could use <body> or <div id="body"> in
both. You could use <div id="error"> if you want the later transforms
to handle errors different from successful content requests. This
complicates your XSLTs and disperses the code formatting error
messages, but may be required. I prefer to create the error message
in the error-handling and present it as a replacement for the content,
with the proper http status code so automated systems (i.e. search
engines) know the page was inaccessible.
solprovider
On 3/10/08, Mark Lundquist <[EMAIL PROTECTED]> wrote:
> Most of my Cocoon applications are websites that pull content
> documents through XSLT templates to add styling/layout markup (and
> navigation menus) before serializing to HTML. So the main pipeline
> starts off with an aggregator that pulls in (1) the content document,
> and (2) a document representing a navigation tree (that's transformed
> by some XSLT to create the nav menus).
>
> So... we got tired of the default Cocoon error pages for production
> instances of these sites, because while there are great for developers
> they aren't very friendly to the general public, and companies think
> they look unprofessional. They would rather have something with the
> normal site look-and-feel, and something that just says "So sorry,
> there was an application error", or a nice "That page does not
> exist" (or whatever) the case of a ResourceNotFoundException.
>
> So, how do I handle the stream that comes out of ExceptionGenerator?
> I can't aggregate it like I do with a resource that I can invoke. The
> problem is with getting the nav tree document into the stream.
>
> Am I makin' sense here? Any ideas,
> cheers,
> —ml—
