I think the algorithm is not quite right How about this for attribute and branch if the QName has a DocumentFactory then the getDocument() method on branch/Attribute should return it, if the element has a parent then return the parents' documentFactory otherwise return the defaultDocumentFactory() (a new factory method, returning by default the DefaultDocumentFatory)
the default for Node should be the same without the Qname bit There should be some documentation in setQName and Qname.setDocumentFactory to indicate the potential issues this will allow for the documentfactory to be defined at any level in the document hierarchy and defaulted by subclasses which I think is more correct in this usage that we are discussing, ie the child elements should be appropriate to their parent, or the nearest parent that defines it When looking at the code (1.3) I note that the implementation of the current getDocumentFActory in AbstractElement (to be replaced with the algorithm above) is I think misplaced and should be in AbstractBranch, and in AbstractAttribute. BTW should setDocumentFactory _be_ allowed, other that the initial set. I noticed it was public with a simple implementation while writing this email Mike -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of James Strachan Sent: Tuesday 30 April 2002 11:28 To: Dennis Sosnoski Cc: Mike Skells (ebizz-consulting); [EMAIL PROTECTED] Subject: Re: [dom4j-dev] generating a QName From: "Dennis Sosnoski" <[EMAIL PROTECTED]> > 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. 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 _______________________________________________ dom4j-dev mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dom4j-dev
