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.
What is Fast Xml DOM ?
Fast XML DOM is wrapper over new Apex DOM classes Dom.Document and Dom.XmlNode. Full details on Google Code Project page here.
How Fast XML DOM helped ?
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
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.