|
HI James, I for one would vote for
getDocumentFactory to be part of the API. I seems to me that the DocumentFactory
is such a core component in the dom4j model that not to have it accessible from
the API is a flaw. Without this API I can see
no way to do large additions to a document, whilst still maintaining the
correct object types. You can use an element and the helper method on that but
that is just a wrapper, and it is not very clean to have an element as a
factory, and perverse if the additions are bottom-up. Are there any compelling
reasons for not having this call in the API, at least on the Document interface? Mike -----Original
Message----- Hi Mike BTW I often find this HTML mail goes
wonky ;-) ----- Original Message -----
Sent: Saturday, April 20, 2002 11:03 PM Subject: [dom4j-dev] generating a QName Hi, I was tidying some code and came across a
problem. I need to retrieve a attribute based on
namespace and name, but via the Element.attribute(Qname) method. I note that there is a convenience method to
generate a QName based on the prefix and the attribute name, but no such method
for Namespace and name Taking a similar line to that in
Element.getQName(String) I could use Element.getDocumentFactory().createQName(
name, myNamespace ); but getDocument is protected, and part of AbstractElement,
not Element. I have 3 questions 1.
What is the preferred way to
generate a QName given a namespace and name? There's either of the following... QName qname = QName.get( "myURI",
"foo:bar" ); Or DocumentFactory factory = new DocumentFactory(); QName qname = factory.createQName(
"myURI", "foo:bar" ); The former uses a singleton cache, the latter
uses a cache per factory instance. 2.
Is here any reason why
getDocumentFactory is not part of the Node interface? I've been really really close to adding it. I
think it might lots of make sense. Its part of the implementation interface;
there's a protected getDocumentFactory() method. 3.
Looking at Qname there
appears to be little documentation – I presume that this class is only intended
to be constructed by a DocumentFactory, or by Nodes Its intended to represent a tuple of
namespace URI, namespace prefix and local name. Creating your own via the
static helpers on QName or via a DocumentFactory is fine too. QName implements equals() based on normal
namespace rules, that the local name and namespace URIs must match, the prefix
is ignored. It can often be useful to declare QNames as
static constant enumerations in your code. e.g. here's a snippet of code from
org.dom4j.datatype.SchemaParser... private static final Namespace XSD_NAMESPACE = Namespace.get( "xsd", "http://www.w3.org/2001/XMLSchema"
); private static final QName XSD_ELEMENT =
QName.get( "element", XSD_NAMESPACE ); private static final QName XSD_ATTRIBUTE =
QName.get( "attribute", XSD_NAMESPACE ); private static final QName XSD_SIMPLETYPE =
QName.get( "simpleType", XSD_NAMESPACE ); James |
image001.gif
Description: GIF image
