[jdom-interest] Adding a DocumentListener interface

[philip.nelson at omniresources.com]

> 
> I have a need for this functionality too, but only when users are
> interactively creating and modifying documents. The rest of 
> the time when
> I'm parsing and processing XML documents, these features are 
> unnecessary.
>snip... 
> Keep JDOM simple, don't add a feature that's only going to be 
> of benefit to
> a subset of applications.

For the most part I agree.  A very few of you may remember this was one of
the first things I brought up back in April.  Since then, I've realized that
supporting Swing guis is probably not a major use case for JDOM directly.  A
wrapper/business class should be doing that.

However, couldn't adding a listener help with some other burning issues?  If
either a Vetoable change listener or JDOM specific variant were defined you
could do things like

class JDOMElementListenerImpl implements ElementListener {

public boolean ElementChanged(Element e) {
	if (e == null) {
		// handle nulls
		return true/false
	} else {
		//check against dtd or schema
		return true/false
	}
}
public boolean ElementAdded(Element e) {
	if (e == null) {
		// handle nulls, even throw an exception if you want ;^)
		return true/false
	} else {
		//check against dtd or schema, rules object
		return true/false //or throw an exception
	}
} 
etc..
}

Second, Jason you mentioned performance hits.  How much of a hit would there
be with no listeners added?  Wouldn't it be comparable to try/catch when an
exception is not thrown?  An approach like this would allow JDOM to be able
to use any DTD parser, any flavor of schema parser for which there was an
independant release, and any custom validation which could be in turn set up
with JDOM documents.  And unlike current tools, these could be used AFTER
parsing, during programatic use of JDOM for element by element checking (and
attribute by attribute checking).

I was hoping to just give this a try but decided to respond when it came up
on the list.  Have I missed the obvious?  It seems like this could work,
would only add two public methods to the various classes (I'll trade you a
getCharXXXX for one addElementListener) and could be ignored without
consequences by anyone who didnt' want to use it.