I still want to mull this over a little bit more though I think I'm getting a closer idea. One of the problems is that setting the DocumentFactory to use on a given node is kind of a multi-dimensional problem - there are various different use cases.
Sometimes folks want to specify a factory for use of a specific named element or attribute, such as in schema-based work or SOAP et al. Using a DocumentFactory on a QName works nicely for this, provided developers get their QNames from a single place (either via the singleton QName.get() methods or via the DocumentFactory.createQName() instance). Sometimes folks want to specify a DocumentFactory on a per-document (or across document) instance. e.g. to attach user data to elements, or implement some different kinda model (persistent model, non-lazy, thread-aware or whatnot). In a similar way certain element implementations might be hard-wired to some factory so that any content added to them will be of a certain kind. (e.g. for persistent elements). The current (admitedly non-public) implementation allows the above; either a factory can be associated with a document, a specific element implementaiton or a qname. So simply making getDocumentFactory() public on the Node interface would fix things I think. Where this might get a bit wierd is if we use the 'if I can't find a factory, use my parents' algorithm that Mike suggested. At first thought this sounds right (and I've been down this road too). It turns out that I think this algorithm might confuse things and break some of the above use cases. e.g. I might want to use a certain 'default' factory for an entire document, apart from all XInclude elements for which I want to use a special factory that implements the XInclude. Using the 'parent' algorithm, this would kinda break as children of XInclude would not use the 'default' factory that it should. So I think I like the algorithm thats effectively... * if the Node has been assigned its own factory use it else * if the QName has a factory use it else * else use the document's factory * else use the singleton's factory I guess we could always have a special element implementation which will use its parents factory instead of its document's factory if folks need it but I think the default case should probably be to use the document (not parent)'s factory. The downside of this could lead (with the current implementation) to excessive navigation up the tree. BTW setting the document factory on a document is used when parsing via, say, SAXReader with a custom factory - the custom factory is then associated with the new document so further modifications via code will use the same factory. So preseving the setDocumentFactory() on a Document is a good thing I think, though not on other nodes. James ----- Original Message ----- From: "Mike Skells (ebizz-consulting)" <[EMAIL PROTECTED]> To: "Dennis Sosnoski" <[EMAIL PROTECTED]>; "James Strachan" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Wednesday, May 01, 2002 8:12 AM Subject: RE: [dom4j-dev] generating a QName > 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 > _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
