Hi Dennis, >From what I understand of the code the Qname lives in a QnameCache which is (generally) owned by the DocumentFactory, The QnameCache in Qname is not used except where by the dom4j code just by the programmer who want more fine grained control (I don't know if there is any real use for it), so I don't think that the comparison is required. I believe that all of the Qnames that exists in the QnameCache cache should have the DocuemntFactory
This could easily be done if we can make a structural change to the code, so that a Qname is an inner class of the QnameCacheand even make QNAmeChahe an inner class of DocumentFacory, so that the documentFactory would be intimately and immutably associated with the DocumentFactory. Would this cause any problems with the current code base? (Probably) Alternativly we could allow for the DocumentFactory to be set only once and throw an IIllegalSTateException if it is modified and exists in it parent documentFatory Qname cache. This will allow for any users of the Qname class directly to be unaffected be the change Or we could change Qname to be a base class/interface and have inner class and other implementations, but the are code implications here as well (<aside> it is a shame that java did not allow for the instantiation of an interface by having a default implementation ...</aside>) Any thoughts /flames ? Mike -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Dennis Sosnoski Sent: Tuesday 30 April 2002 18:55 To: James Strachan Cc: Mike Skells (ebizz-consulting); [EMAIL PROTECTED] Subject: Re: [dom4j-dev] generating a QName Using the element's or attribute's QName to track the DocumentFactory implementation gives fast lookup with little added overhead. Right now the DocumentFactory connection is kind of operating behind the scenes, though. To make it work cleanly you'd need added methods to specify the DocumentFactory for the get() QName calls, and also need to include the DocumentFactory in the QName cache comparison (so that the same QName could be defined with different DocumentFactories). If no DocumentFactory were specified you could just set the default factory when you construct a new QName. - Dennis James Strachan wrote: >This feature allows different named Element/Attributes to have different >factories. e.g. JAXM uses this feature to create different Element >implementations for a SOAP Envelope, Header and Body. Similarly the >datatypes support uses this feature to create type-aware (int, date, float >etc) Element and Attributes based on the 'type' in the schema. > >So if the QName has a DocumentFactory then the getDocument() method on >Element/Attribute should return it, otherwise return the document's >DocumentFactory - is probably a good algorithm for now. > >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
