jhunter at acm.org
Wed Jun 28 17:21:42 PDT 2000
I was just perusing through Enhydra's XMLC package and in there they
have a class called DOMFormatter that plays a role similar to JDOM's
XMLOutputter. What's interesting is they have an OutputOptions class
they pass to its constructor where they tweak behavior. It's not as
powerful as what Elliotte proposed we could do through subclassing, but
it does seem like they covered most of the common bases, and we could
still allow subclassing for power uses:
void setIndenting(boolean enable)
Enable or disable indentation.
void setIndentSize(int size)
Set indentation size.
void setJavaEncoding(java.lang.String newJavaEncoding)
Set the encoding using the Java encoding name.
void setLineWidth(int width)
Set the width at while long lines are split
when indentation is enabled.
void setOmitEncoding(boolean omit)
Set flag indicating if encoding should be
omitted from the XML header.
void setPreserveSpace(boolean preserve)
Set the default space-preservation flag.
void setXmlEncoding(java.lang.String newXmlEncoding)
Set the encoding using the XML encoding name.
void setXmlEncoding(java.lang.String newJavaEncoding,
Set both the XML and Java encodings.
It's interesting they have separate Java encodings and XML encodings.
Presumably they want to support "UTF8" in Java but "UTF-8" in the XML
file? I wonder what encoding makes that necessary. Any ideas why you'd
Flags that we definitely could use would be setLineWidth() and
setPreserveSpace(). It's interesting we've been talking about those
lately. Whether encoding should be done as a boolean/int as they do or
just as a String as we do (where "" means no indent, " " means two
space indent, and "\t" means tab indent) is debatable. Also debatable
is if it's better to pass an "options" object or just call setXXX()
methods directly on the outputter.
More information about the jdom-interest