Creating An ArgumentArray Collection In ColdFusion 9 Using TreeMap

@Ben, just as an aside on maps:

For all intents and purposes, you can think of java.util.HashMap as a ColdFusion struct and java.util.TreeMap as a struct on which you've done x = ListSort(StructKeyList(struct)) and you're using x to iterate over the struct. That is, TreeMap is like an ordered struct.

But on the Java level, they have a very interesting other usage. If you have a very large number of incoming things to sort, you can use HashMap to gather them together quickly. (When the number of elements gets large, doing a put to a HashMap is much faster than a TreeMap.) Then, when you're done, you can build a TreeMap from the HashMap all at once like so:

TreeMap map2 = new TreeMap (map1);

... where map1 is the HashMap.

All subclasses of Map (that I know of) have a constructor that takes another Map as its only argument. The cool thing about that is, the TreeMap does a one-time sort that's "of order n log n", if you know what that means. For everyday situations, sorts of order n log n are pretty much the best you can do (fastest available).

The key phrase there was "one-time". If you do lots and lots of puts to a TreeMap that you're building from scratch, you're having to maintain the sorted order on every stinking put.

It's a space versus time tradeoff. You're using twice as much Map space to achieve an improvement in time. Presumably, the objects pointed-to by both maps would be shared. That is, I'm pretty sure that it's a "shallow copy". The difference is that, if you define an Iterator over a HashMap, you get unsorted, but if you define an Iterator over a TreeMap, you get sorted.

Just an idea to hold in reserve for when you have a large collection to sort. I know you love ideas.

Here's what I used it for:

When the size of an XML file gets really big, if there's any error at all, the sender complains that they did everything right(!!), and my software is goofing up. They were never right. It was always their lack of familiarity with XML rules that caused the problem. But by saying it was our fault, to prove them wrong, I had to do their debugging for them.

They would always apologize profusely for their XML generation mistake, but in the meantime, I had done their debugging for them. So naturally they kept complaining first, before even looking at their own code. As the number of people sending me XML multiplied, I had to find a way to keep from having to do everyone else's debugging for them. I needed to isolate the cause of the problem in software.

So I hit on the idea of using a SAX parser. That way, I could quote them chapter and verse: the exact tag number where their XML generator screwed up. Also, SAX parsers parse XML much faster than DOM parsers, making them more appropriate for large XML submissions.

The problem is that, after parsing, you want to process the data according to particular tag names, not sequential order. So I hit on the idea of sorting the parsed data by a string that represented tag inclusion hierarchy (not XPath, more simplistic). That string was the HashMap key, which became the sorted TreeMap key.

Now, if they mess up, we tell them "You Bozo! You messed up at tag 1234 (MiddleInitial), whose parent (FirstName) is a data tag, not a group tag!", and they realize that they forgot to close FirstName.

(Well, we don't exactly call them Bozo, but you get the idea. And TreeMap made it possible.)

The core of what you have to do is extend javax.xml.parsers.HandlerBase (and in my case, also implement CustomTag). Extending HandlerBase defines empty callbacks for you, the most useful being:

• startDocument,
• endDocument,
• startElement,
• endElement,
• characters (to grab data between elements) and
• error (if you want to implement a parser that validates against a DTD/XSD).

When I say empty, I mean {}, no code. But since you're subclassing HandlerBase, you can implement your own methods by those same names, and they override the empty ones. Any methods you don't want to implement, don't. (The HandlerBase empty method will be called, and do nothing.)

A minimalistic SAX parser would implement only startElement, endElement and characters. Here's some pseudocode:

public void startElement (String tagName, AttributeList a)
throws SAXException
	{
	// set up a property to receive the data
	}
public void characters(char buf[], int offset, int len)
throws SAXException
	{
	// Do something with the characters,
	// based on the property that startElement
	// set up.
	}
public void endElement (String tagName)
throws SAXException
	{
	// Do something with the data you captured.
	}

These are called repeatedly as start and end elements are encountered. All the real work is in startElement, which cleverly figures out where to store the element's upcoming data.

That's why they call it SAX, the Simple API for XML. The API's as simple as can be. But startElement can get pretty complex, depending on your XML format.

There's a LITTLE more to it than that (instantiating with SAXParserFactory), but the core of the work is in those 3 methods.