I hadn't considered the extra instance data issue - looking at the code I see you've avoided storing a reference to the document and instead just walk up the tree on a getDocument() call.
But the QName *does* store a reference to the documentFactory. How is that intended to work? It seems like it'd cause problems if the same QNames are used with different documentFactories. - Dennis James Strachan wrote: >I agree with both of you on this - I nearly went this route back in dom4j >0.2 or 0.3. I think its a good idea. > >My reservation was initially mostly to do with avoiding the extra instance >data or the walk up the tree to get the Document instance on which to get >the DocumentFactory from. Though I think this would make the API much >cleaner so think we should do it. > >James >----- Original Message ----- >From: "Dennis Sosnoski" <[EMAIL PROTECTED]> >To: "Mike Skells (ebizz-consulting)" <[EMAIL PROTECTED]> >Cc: "James Strachan" <[EMAIL PROTECTED]>; ><[EMAIL PROTECTED]> >Sent: Tuesday, April 30, 2002 9:03 AM >Subject: Re: [dom4j-dev] generating a QName > > >>I asked for this a long time ago, too. If you're working with a document >>you'll virtually always want to create new components with the same >>factory as used for the rest of the document. The addXXXX() methods let >>you do this already in most cases, but these methods aren't always >>usable. Making getDocumentFactory() a public part of the API would give >>a clean solution for all cases. >> >>- Dennis >> >>Mike Skells (ebizz-consulting) wrote: >> >>><cid:[EMAIL PROTECTED]> >>> >>>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----- >>>*From:* James Strachan [mailto:[EMAIL PROTECTED]] >>>*Sent:* Tuesday 23 April 2002 14:51 >>>*To:* Mike Skells (ebizz-consulting); [EMAIL PROTECTED] >>>*Subject:* Re: [dom4j-dev] generating a QName >>> >>><> >>> >>>Hi Mike<> >>> >>><> >>> >>>BTW I often find this HTML mail goes wonky ;-)<> >>> >>><> >>> >>>----- Original Message ----- <> >>> >>>* >>>From: Mike Skells (ebizz-consulting) >>><mailto:[EMAIL PROTECTED]> >>> >>><>* >>> >>>** To:* [EMAIL PROTECTED] >>><mailto:[EMAIL PROTECTED]> <>* >>> >>>** 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 should be something better than appending the prefix 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*<> >>> >> > > >_________________________________________________________ >Do You Yahoo!? >Get your free @yahoo.com address at http://mail.yahoo.com > _______________________________________________ dom4j-dev mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dom4j-dev
