Migrating from Apex XMLDOM Parser to Fast XMLDOM !

I recently helped a friend of mine migrating from Apex classic XMLDOM library to “Fast XML DOM”. The reason he migrated was

Heavy script statement usage for big XML response. Operations like DOM creation, eats a huge chunk of script statement quota. Even after operations like getElementTagName are costlier.
Spring’10 Dom API differences: To solve the above script statements problem, he can migrate to new Dom.Document and Dom.XmlNode classes released in Spring’10. Unfortunately, this API is not following standard W3C DOM API’s, all the method signatures and approach of DOM handling are way different for smooth transition. So a learning curve, plus more testing is required for migrating to Spring’10 Dom classes. More details about this in previous blog post here.
Unamanged Package Issues : Issues in installing unmanaged package, having XmlDom. XmlDom Apex class is available by default in many SFDC Orgs. His plan was to move to managed package later on, but want to hold off that decision, until his force.com app stabilizes for changes.

So I suggested him moving to Fast Xml Dom library, this library solves all the above problems.

Fast XML DOM is wrapper over new Apex DOM classes Dom.Document and Dom.XmlNode. Full details on Google Code Project page here.

As both XMLDOM and FastXmlDOM follow W3C DOM specifications, learning curve is minimal. So one doesn’t needs to learn a new API for DOM operations with XML. All standard methods are available in both API’s like
- getElementByTagName(..)
- getElementsByTagName(..)
- toXmlString()
For XMLDOM to FastXmlDOM migration, mostly requires simple token replacement, no logical code changes. One mostly needs two token replacements for these classes [and a few minor changes] i.e.
- Xmldom > TG_XmlDom
- XMLdom.Element > TG_XmlNode
Eats very less script statements as compared to XMLDOM, as its using native Apex Dom.Document and Dom.XmlNode for Dom operations. Full bench marks of XMLDOM vs FastXmlDOM, available in my previous blog post here.
As FastXMLDOM classes are not included by default in new SFDC orgs, chances of unmanaged package installation failure will be less.

Want to start with FastXmlDom, here is the quick start guide.