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
