Re: XHTML Serilization instead of HTML S.
On Thu, 19 Sep 2002 [EMAIL PROTECTED] wrote:
well, thank you, I basically know this, but to come back to the point:
I DO NOT want to learn how to make correct XHTML, what I want is, that
Cocoon renders correct HTML.
*that* is the point!
any suggestions?
Sorry, I missed your initial message, so I'm not sure exactly
which aspect of the output is problematic for you. As you
know (?) you can certainly configure the DOCTYPE with suitable
doctype-public and doctype-system within map:serializer;
the problem I have encountered is that, nonetheless (and using
the HTML serializer) the output retains xhtml namespace
attribute(s). If this is your problem, you can use an xslt to get
rid of them, as a penultimate pipeline stage:
map:match ...
...
map:transform src=xslt/strip-xhtmlns.xslt/
map:serialize/
/map:match
where strip-xhtmlns.xslt is attached below.
(Of course namespace attributes will still appear if the input to
strip-xhtmlns has elements with any namespace other than xhtml;
and this use of xslt may be taking a sledgehammer to crack a
nut - with consequent performance impact).
Does this help?
- Barry.
?xml version=1.0?
xsl:stylesheet version=1.0
xmlns:xsl=http://www.w3.org/1999/XSL/Transform;
xmlns:xlink=http://www.w3.org/1999/xlink;
xmlns:xhtml=http://www.w3.org/1999/xhtml;
exclude-result-prefixes=xlink xhtml
!-- Match the document to bootstrap... --
xsl:template match=/
xsl:apply-templates /
/xsl:template
!-- For all xhtml elements we throw away the xhtml namespace;
this is based on the assumption that the output
will be HTML 4 (rather than XHTML). Note that we can't do
this with xsl:copy which provides no mechanism to change the
namespace on the copied nodes; so, instead, we use
xsl:element to manually copy. The throwing away of the
namespace then occurs by virtue of the
exclude-result-prefixes on the xsl:stylesheet element
(above). I expected that the same effect would be achieved
more elegantly via the namespace attribute on xsl:element
(by giving it the empty string value ) - but that doesn't
seem to work, so my expectations are evidently mistaken
there! --
xsl:template match=xhtml:*
xsl:element name={local-name()}
xsl:apply-templates select=@*|node()/
/xsl:element
/xsl:template
!--
Whereof we cannot speak, thereof we must be silent
- Ludwig Wittgenstein.
--
xsl:template match=@*|node()
xsl:copy
xsl:apply-templates select=@*|node()/
/xsl:copy
/xsl:template
/xsl:stylesheet
-
Please check that your question has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
aggregation and exception (404) handling - how to?
Hi -
I'm attempting to configure a simple toy site with cocoon
(2.0.3). I have a pipeline which delivers (almost) all pages by
aggregating a content xml file with a navigation xml file
(and doing a little transformation on the result). This is
matched on almost every URI I get:
map:match pattern=**
map:aggregate element=page ns=http://eaccess.rince.ie/xmlns/local;
map:part src=template/site-nav.xml/
map:part src=content/{1}.xml/
/map:aggregate
map:transform src=xslt/page-layout-tables.xslt/
map:transform src=xslt/strip-xhtmlns.xslt/
map:serialize/
/map:match
My problem: because the pattern match is (deliberately) so broad,
this matches nonsense URIs - for which I would like to return a
proper 404 status. But - apparently - if a map:part doesn't
generate any content (in this case because the corresponding file
does not exist) that does not raise any exception for the
pipeline as a whole. So if I use a nonsense URI, instead of a
404 I get a page with an empty content part (and a normal
navigation part).
I have tried moving the reading of the content file into a
pipeline of its own (and using the cocoon: protocol in map:part
to get to it). If I contrive to use that pipeline in isolation,
for a nonsense URL, I get a standard cocoon exception page
(albeit with a 500 status instead of 404); but when I use the
aggregating pipeline it still silently returns an empty content
page.
As far as I can see, map-error-handler is not relevant to this
(as it would only allow customisation of the error page - but I'm
not getting such a page at all?).
I have trawled both the docs and the mailing list, but without
finding any clear guide on what to do here (but I freely admit
I'm only slowly coming up to speed). I can imagine a variety
of ways of fixing this; but I'm wondering is there a preferred
or recommended approach - it seems like a fairly general issue?
Thanks,
- Barry.
--
-
Please check that your question has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: aggregation and exception (404) handling - how to?
On Tue, 17 Sep 2002, u15603 wrote: I think it is a known bug! You could find it in the buglist, with this link: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12293 Thanks Dirk - I guess it would be comforting to feel that this is a cocoon problem (rather than just a problem of my own ignorance/incompetence in using cocoon)! I have browsed the bug report; I don't know enough of the cocoon internals to really judge whether it is likely to be at the root of my issue. In particular, it is not immediately apparent to me that the mechanisms mentioned in this bug report are (also) triggered in the implementation of aggregation. Is there a knowledgable developer who can confirm that diagnosis (or maybe Dirk is already sure of that)? Thx, - Barry. - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: aggregation and exception (404) handling - how to?
On Tue, 17 Sep 2002, Antonio Gallardo Rivera wrote: You need the map:handle-errors element inside your pipeline, for example: map:handle-errors map:transform src=stylesheets/system/error2document.xsl/ map:transform src=stylesheets/apache.xsl/ map:serialize status-code=500/ /map:handle-errors I don't *think* so ... but I am open to correction. The problem, as I see it, is that no exception or failure is being raised in the relevant map:match *at all* (in the case of doing an aggregation, and only one part is missing) - so there is nothing to trigger a map:handle-errors. But, for the record, I just added a degenerate: map:handle-errors map:serialize status-code=500/ /map:handle-errors to the pipeline, and it makes no apparent difference to the behaviour. (As an aside: my understanding is that cocoon would only automatically generate a 404 status when no matcher is found for the URI at all - is that right?) Best, - Barry. - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
