cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Heinicke <joerg.heini...@gmx.de>
Subject Re: TidySerializer
Date Tue, 03 Jun 2003 21:46:20 GMT
Torsten Knodt wrote:
> On Tuesday 03 June 2003 22:29, Joerg Heinicke wrote:
> JH> 1: A solution for the HTMLSerializer was discussed
> JH> (startPrefixMapping(), endPrefixMapping()). Maybe TidySerializer
> JH> provides a better solution, but I guess this can be adapted too.
 >
> A little more would be nercessary. You would have to map all xhtml namespace 
> to default prefix and remove the declaration. All other namespaces would have 
> to generate an error. When I know someone will commit it, I can make this 
> patch for HTMLSerializer.

IMO this (a patch to HTMLSerializer) is the best option we have and I'm 
sure it will be applied.

> JH> 2: Human readability is as you say for debugging reasons. This needs not
> JH> to be done on live systems. We use IMO a better way: on the last
> JH> transformer step we add a label="format". We access a page in debugging
> JH> mode via test.html?cocoon-view=format. The view "format" is simply a
> JH> further transformer step using format.xsl and the XMLSerializer. The
> JH> different between live and debugging mode is the URL, not the sitemap.
> JH> And there is no need for second component.
 >
> You can use tidyserializer for the same via views. For this purpose, a 
> stylesheet would also be OK. But it wouldn't be simply indenting. You have to 
> check for xml:strip-space and friends. That's why I haven't done it so far.

For debug output I normalize-space every text node and simply indent 
them by counting the ancestor nodes. This has no influence for HTML, 
because HTML normalizes text nodes too (exception: <pre/>).

> JH> 3: Also only for debugging, isn't it?
> 
> Yesno. I want it as part of quality assurance.

Understandable ...

> JH> Validating every request on live systems is too much resource consuming.
> 
> Not that real, when it (hopefully) is integrated in xalan some time. For xslt 
> 2.0 type handling, there has to be (IMHO) validation inside. It only has to 
> be forceable for output.

But it's also resource consuming if it's integrated in Xalan :)

> JH> And what do you want to do on
> JH> live systems when a validation error occurs? A message "We can't deliver
> JH> the page, because it's not valid HTML"?
> 
> Redirecting to a internal error page, like with other errors to.

What's the advantage for the user? Who cares about invalid HTML pages? 
It's only important for development, must no be running on live systems.

> JH> But you have other
> JH> possibilities, e.g. using http://validator.w3.org/ or a mix of Jakarta
> JH> commons httpclient with Tidy as we did. If you integrate this in a test
> JH> system you can validate your pages automatically.
> 
> That's what I actually do more or less. I validate all generated files via 
> xmllint. I am looking for a cleaner solution which enforces this already in 
> cocoon. When this is a parameter or a view, even better.

Ok, reason accepted :) But what about an extra validating transformer as 
last pipeline step? Seems to make more sense IMO.

Joerg


Mime
View raw message