Hi Pier --
Pier Fumagalli wrote:I basically fixed the GARBAGE serializers to work now cleanly as cocoon serializers, simple job, but as far as we could see, the new ones work much _MUCH_ better than Xalan's own (they might be slower, but they're more compliant).
I've been using your XHTMLSerializer as a Cocoon serializer for a little while now on the project I'm developing, and I can report that it has been working very well (although I have not yet tested it in production). Since I am very concerned with the way the XHTML looks, I added the following features to the XHTMLSerializer and XMLSerializer:
- Option to omit xml declaration
Nice feature!
- Option to omit xml namespace declaration
That's absolutely brillant...
- Option to omit meta tag
Hehehe! :-) I think you noticed the same one I did:
http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/src/webapp/welcome.xslt? annotate=1.11#37
That "meta" tag scares me, as it assumes that the content is serialized in XHTML with UTF-8
- Explicitly set which namespaces are declared on the root element, and prevent these namepsaces from being declared later in the document.
Oh, that's pretty! :-)
- Option to declare other namespaces
- Intending, including the ability to indent some elements, and put a break after some elements. This lets you have a document that looks like:
<html> <head> <title>this is the title</title> </head> <body> <div> <p>a paragraph</p> </div> </body> </html>
I would also like to do some work with whitespace minimization, but haven't really looked into it yet.
You might want to specialize the HTML serializer to strip the unneded whitespace and re-indent it "nicely", kinda like a very pretty-printer serializer
- Option to enable compatibility mode as described in:
http://www.w3.org/TR/xhtml1/#guidelines
This determines the treatment of empty elements that are not declared as EMPTY, as you already implemented. It would be nice to extend this to include all of the compatibility guidelines. I also tried implementing an "auto" mode that could detect if compatible content should be served (e.g. if the browser is IE), but could not figure out how to 1) read the User-Agent in the serializer, or 2) change the content type of the response on a per-request basis.
Ah....
To make a Cocoon serializer out of the XHTMLSerializer, I took the simple solution and just wrapped it around a new AbstractSerializer subclass. There probably is a better way.
I removed some of the methods (setOutput, getContentType) and replaced them with the Cocoon's own, (getMimeType, setOutputStream, ...) and implented the configurable interface for the encoding...
Two hours work, but working...
Also, I've changed the package to be org.apache.cocoon.components.serializers.(XML|XHTML|HTML)Serializer, and cleaned up the code a bit... Included them into a nice block with simple configurations (it automatically puts them into the root sitemap, now), and as you might have noticed, added a number of extra charset encoders for more i18n support (those are automagically generated, so, it's no biggie).
You are absolutely welcome to all of this code that I have added (there really wasn't much added thanks to your clean design). I was planning on cleaning this up and offering it back to the community, but I have not had the time.
That's great to hear! :-) If you could include your changes once I put them in CVS it would be absolutely fantastic... You might have to do a little bit of mangling including them as a couple of methods have changed (and maybe a direct patch of the source might fail) but my changes were so trivial that the core bulk of the entire design is still there, untouched.
Pier
smime.p7s
Description: S/MIME cryptographic signature
