Processing instructions and Microsoft XML DOM

If you're using Microsoft's XML DOM you'll find it strips out the encoding attribute from your processing instruction (the <?xml ... ?> bit) when you get the value of the Xml property. This is because it always returns unicode regardless of what the input encoding was. As unicode is the default for the XML specification, no encoding attribute is required.

The Save method, which writes the contents of the DOM document to a file, maintains the original encoding. If you need your XML in the original encoding after some manipulation in the DOM then you can do this:

xmldoc.Save("c:\blah.xml")
Set fs = Server.CreateObject("Scripting.FileSystemObject")
Set ts = fs.OpenTextFile("c:\blah.xml")
strXml = ts.ReadAll

Programmatically changing a processing instruction

Looks a bit dodgy but this is the way to do it:

Set pi = xmldoc.createProcessingInstruction("xml", "version=""1.0"" encoding=""UTF-16""")
xmldoc.replaceChild pi, xmldoc.childNodes.Item(0)

Mapstraction "to do" list

I've been using Mapstraction to implement draggy maps in our platforms at work for the past month or so and thought I'd share some of the problems I came across so, should you decide to do the same, you know what to watch out for. The issues I've come across below I've fixed for the APIs with which I was working and I'll be submitting the changes back to the project in the near future.

I should say first that Mapstraction is an awesome piece of work that frees you from having to commit to one mapping provider. When clients don't want to pay for maps so you give them Google and then change their mind when Google start inserting advertisements, all you have to do is change one line of code.

The List

1. Patchy implementations

Mapstraction abstracts the lowest common denominator set of functionality for its supported APIs. I've been working primarily with Multimap and have discovered that, for this API at least, some API classes are missing methods or have non-working implementations.

In the Multimap case this is just a few methods here and there but the thing I found annoying was that, rather than the method just being empty or throwing a "not implemented" exception, the method was populated with the code for one of the other APIs.

2. Incomplete events

The only events catered for by Mapstraction are "move end" and "click" which is severely limiting considering the vast array of events available through the native APIs. Events like "zoom", "open bubble", "change map type" etc aren't there.

Arguably, abstracting events is probably the most difficult part of the process as you have to take into account differences in when similar events fire, orders that they fire and event arguments that are passed back to the handler.

The event implementation for the two events also doesn't cater for overriding the scope in which the handler function is to be executed via the call method which is essential if you're working with methods of JavaScript objects.

3. No namespacing or prefixing

The Mapstraction code is not namespaced, scoped or prefixed in any way so is dangerous when used with a lot of JavaScript code from different sources as you'll likely end up with name clashes and global variables being overwritten.

4. No standards enforced on the source code

There appear to be no coding standards enforced on the source. It's full of undelared variables, dodgy constructs and some bits that just aren't formatted well, making the code difficult to follow.

The likes of Yahoo! run all their code through JSLint before it goes anywhere near deployment and with a library of this type I think at least a loose Linting is a must.

To sum up

If your integration is complex and requires a lot of event handling and dynamic manipulation of the map artifacts then Mapstraction isn't quite there yet but for most other things it's worth filling in any holes yourself for that freedom of API.