[jdom-interest] More changes

[Patrick Dowler]

On Wed, 19 Jul 2000, Brett McLaughlin wrote:
> OK folks... some more food for thought:
> 
> * Anyone having a problem with removing getCharContent() (both default
> and non-default version) in Element.java? It doesn't really behave the
> same as the rest...
>
> * What do people think about removing the convenience methods (like
> getIntContent()) on Element.java? Mark Diekhans pointed out that getting
> a default value from an attribute is quite different from getting one
> from an Element - typically, it means the Element is optional, or not
> there, but we also return the default if the /format/ is incorrect.  For
> example:
> 
> <port>yl7</port>
> 
> getPort(80); 

These methods could go as they are just as already there in the
java.lang type-wrapper classes:

	try
	{
		int i = Integer.parseInt( element.getContent() );
		// do somehthing
	}
	catch (NumberFormatException ex)
	{
		// handle format error
	}

You really do want an error condition (here and exception) for a
formatting error in the content.

> List kids = element.getChildren();
> 
> Do you expect the list to be live? For example, if you add kids to an
> element in the list, of course it works normally. However, if you add or
> remove children from the list, do you expect those to automatically
> cause removal of the children in the List? Or do you not expect it to
> take place (the removal or addition) until you do
> element.setChildren(kids); and reset the list with the modified one?
> This is a key point I would like to get feedback on, and decide if what
> we are doing is right. If not, we can remove PartialList, and really
> simplify things. Additonally, it makes traversal much less
> object-intensive.

Some relevent bits of java.util:

	List.subList 
		- returns a "view" which is backed by the whole list
		- allows all the whole list operations to be performed as
			range operations
		- supports all operations permitted on the backing list

	Map.entrySet (keySet, values)
		- returns a "view" which is backed by the map
		- supports removing 
		- does NOT support adding!! -- seems strange?

If we take the style of the Collections API as the "java style" then a view
approach seems valid. But - we still have to decide if an Element is a
List (of children) or a Map (since Elements are name/value pairs, although we
certainly allow duplicates, so a strict Map isn't correct). The current use is
to think of them as Lists... I think that means keeping PartialList and
backing it with the child list.

***

An alternative plan might be to implement "iterator" access to the underlying
list instead of a view-based access. I recently wrote a FilteringIterator
base class that can easily be access a subset of a collection. It basically
skips over the elements that don't meet some condition. Subclasses 
implement a boolean method. It turns out to be a very efficient way to
look at parts of a list. For example, I had one that only returned Strings
that contain a specific substring. Another implementation only returns 
objects which are instances of a specified Class. It wouldn't be too hard to
extend it to be a full ListIterator (previous) and support removal as well.
I'd be happy to contribute it if you like.

As for the effect on Element, these filtering iterators wrap a normal
Iterator (or ListIterator) so Element would just need one (two) methods:

	public ListIterator children() { }

	public ListIterator attributes() { } // probably useless

Then usage would be something like:

	// get all Element children
	ListIterator iter = new TypeIterator( el.children(), Element.class );

	// get all children named "foo"
	ListIterator iter = new NameIterator( el.children(), "foo" );

The down-side (which will certainly be expressed :-) is that some people prefer
indexed access over iterators. Our use of LinkedList inside seems to
suggest that is a bad plan, but still...

Returning a "view" List still lets people use iterators, but possibly with one
extra wrapper level. 

-- 

Patrick Dowler
Canadian Astronomy Data Centre