RE: [dom4j-user] DocumentFactory Methods Not Being Called for All Elements

[Mike Skells]

Title: Message

Hi,

The model of the communication between the saxparser and the system, is a very small part of the API sets that can generate XML nodes, so the model correctly chosen was to use the nodes to determine the creation mechanism. If the model chosen was the one that you suggest there would be a reduction in the flexibility, for no great advantage, and subsiquent creation on nodes done via XSLT, programatic access ..... would not use the factory.

 

 

-----Original Message-----
From: O'neil, Jerome [mailto:[EMAIL PROTECTED]]
Sent: Thursday 17 October 2002 22:55
To: 'Mike Skells'
Subject: RE: [dom4j-user] DocumentFactory Methods Not Being Called for All Elements

I understand what it's doing.  I just don't think that's how it aught to do it.  Allow me to pontificate for a bit.  :)

> The element becomes aware of the factory( that created it) by the QName. The QName is
> created by the documentfactory itself, so by default this behavior works without you
> having to do anything

My position is that nothing generated by a factory needs to be aware of the factory that generated it.  The SAX parser should be making calls to the factory assigned to it as it parses it's input stream.  I don't want to rely on one node's state for future generation of it's children. 

It is not relying on the state, it is relying on the semantic behavior. What is the behavior that you expect the node to have for future child node creation?

> So if your document factory returns elements, then the elements are aware of the
> document factory, by virtue of the qname that is passed to them.

This is only true if I use the passed in QName, and not a String, as the argument to DefaultElement's constructor.  If I use a string, the behavior of DefaultElement is to go to a new instance of DocumentFactory, and ignore the factory I set on the SAX parser.  I can't override getInstance() in my factory, as it's static. This means I must override getQName() to set it's factory to reliably create Elements.  This is the heart of my beef. 

No, as I said, the QName createion is wired by default of the document factory that created it. Look at the code in the document factory. It is inherently aware on the document factory instance. When you designed your application I am sure that you considered the detail of what you had to enhance, and therefore as a general rule you should look at the existing code base. I presume that you looked at the DocumentFactory.createElement methods, and you would see that they all use the qualified name constructor for the element. As such when you change the model of behavior, you need to assess the impact. 

If you had used the same semantics, and passed a QName then you would have the problem would you?  

In Jerome's Perfect World(tm), there is no need for any factory artifact to be aware of the factory that created it. The parser makes calls to the factory as it parses, and populates its tree with the result.   

And that is the way that it would have worked, if you hadnot broken it ;( 

One way to solve this is to define DocumentFactory as an interface, and create DefaultDocumentFactory, and it's derivatives that implement it.  The SAXReader is assigned a DocumentFactory to use.  All elements are then generated from that factory, and that factory only. 

AS I explained, the parse fro SAX is one of the many ways that a document can be changed.

I am personally if favor of having the DocumentFactory as a publically accessable bahavior of the Node, and have interface/base class etc model. It would not however solve this issue, which is the semantics of the factory. The factory is a tools to be used in the application, what you are proposing is a constraint, which only works during the parse, and then only from SAX.

JDOM works this way, and despite JDOM's many warts, this isn't one of them.  

JDOM does not use factory properly at all last time I looked. (I used to develop with it) 

> They use the default document factory if the qname does not know of a document factory

Exactly.  I don't want it to (nor should it) use any document factory other than the one I assign it, and I shouldn't need to assign it more than once. 

And that is the was that it works! The problem was that you deassigned it by calling the wrong constructor.AS a rule of thumb look at the working code as use the same semantics, unless you understand the impact. Was there a good reason for not using the QName constructor 

I've attached a package that demonstrates what I'm talking about.  You can see that the direct descendents of my DefaultElement derivative are never handed to my factory. 

I would be supprised if the default elements pass the calls back either as you are using getQualifiedName (which is a qualified name string) and passing it into a string based constructor, what is expecting a name (i.e. no qualification). This is broken! Do not confuse the QName and the qualified name, and the name. Your document factory method was given a prefectly formed QName, which was aware of the document factory, namespace etc, and you disgarded the namespace, the documentfactory, and passed the qualifed name (i.e. x:fred) to a constructor that is expecting a non qualified name, in the default namespace. You have therefore taken away the capability to use namespace in you application. (NB if you used your code in a documant that had namespaces, some code may work, and the XML will probably be generated OK back to disk, but getNamespace(), or xpath queries will fail)

why wasnt your code 

  if(<some condition>)
   element = new Layer_2(name);
  else
   element = new DefaultElement(name);

  return element;
 

I really like the dom4j model (it's vastly superior to JDOM's), but the factory behavior is much more complicated than it needs to be. 

It is actually simple if you dont throw away the information thatyou are given ;) 
I agree that there needs to be some more guidance for implementing custom document factories, so that the semantics are presented, however the model is correct.

As a general point, you should always use the QName based methods, but this is just common sense, as it promotes encapsulation. The model assumes that this would be the default mechanism that is used, to support standard software engineering practice, and the most basic principles of OO.

Thanks for the feedback.

-Jerome

I hope that the above makes sense

Mike