April 23, 2010

Edit Static resources via Force.com Eclipse IDE !

As a Apex & Visualforce developer, we create static resources for our custom javascript and css code. A general development practice is to keep javascript/css inline in visualforce in development and upload them as static resources when moving to production. This approach turns painful when we need to update the JavaScript file or change some styles in css. This requires you to either

  • Download the file locally via the SFDC website and uploading back again once changes are done.
  • Or move the JavaScript or CSS code inline again in Visualforce to do the updates.

Today I explored a really cool thing about force.com IDE. You know we can avoid the above hassle and work directly with static resources just like normal apex classes in Force.com IDE.

For ease of demo, I have created a sample Visualforce page that contains some “INLINE” CSS and Javascript markup, I named this page “StaticResourceInline”. This page uses CSS class to style a heading(h1) with huge red font and replaces contents of a div via javascript.

Following is the code for that page

    <style type="text/css">
     Some inline CSS code
    .customH1 {
       color: red;
    #sample {
       padding: 20px;
       margin: 10px;   
       clear : both;
        <h1 class="customH1">Congratulations, you must see this text in huge RED font</h1>
        <div id="sample">
         This will be replaced by script
    <script type="text/javascript">
      // This is sample inline script that replaces a div's content
      document.getElementById('sample').innerHTML = 'This is updated by Script';


On execution this page will display something like this

Now to follow good practices, I moved the CSS and Javascript Markup as static resources. As shown below:

Now I changed the visualforce code to remove inline css/js references and use these static resources. Here is the sample code that shows this change

<apex:stylesheet value="{!$Resource.SampleCSSResource}" />

    <h1 class="customH1">Congratulations, you must see this text in huge RED font</h1>

    <div id="sample">
     This will be replaced by script

<script type='text/javascript' src="{!$Resource.SampleJSResource}"></script>   


Now as before this visualforce page renders the same page. As we haven’t changed anything.

The Change Request

Now lets say there comes a requirement to “Change the heading text color to GREEN”.  For this change request one way is to download the static css resource “SampleCSSResource.resource” and upload it back again with changes. This might require a couple of download/upload iterations to get the pixel perfect style, obviously in case of complicated style changes.

Ease Alternate to test and fix

An easy alternate is to work directly on static resources in Force.com Eclipse IDE. I am assuming you have this visualforce project checked out in your Force.com IDE. All you need to do is to goto “Static Resources” under “classes” in Package Explorer.


As we need to update the CSS style, just open the “SampleCSSResource.resource” in default Eclipse editor (double click the SampleCSSResource.resource file in package explorer). You will see the CSS code directly available for editing, as shown below


That's it man you are done, just go ahead and change the styles and do save(CTRL+S). Your static resource will be updated on salesforce servers like normal visualforce pages and apex classes etc.

For example I changed the heading style color to GREEN from RED as shown below. The updated page is also shown next.

image  image


Similar changes can be done directly on the javascript static resource i.e. “SampleJSResource.resource”. All the SAVE done via Eclipse will be directly applied to the visualforce page without any extra upload.

Important Note

The practice of using Static Resources via Eclipse is only applicable to static resources uploaded as text files i.e. with MIME type text/css or application/x-javascript. If you are uploading a zip file containing all your css, javascript and images this approach will not work.

April 13, 2010

IE 9 Chrome Firefox Opera, IE still a loser !

Internet Explorer 9 is available for test drive @ http://www.ietestdrive.com/. I am not an IE fan. I only use IE as a developer, to fix my web applications with IE specific issues. I trust acid tests as its widely accepted open web standard for web related tests. So I tried to do a quick comparison of IE-8, IE-9, Webkit(Chrome + Safari), Firefox, Opera on the basis of these acid tests.

Acid Test Scores

I checked IE Blog long time back when IE 9 was in development and was just scoring 32/100 in acid tests.

Even today when Microsoft released IE 9 for test drive, and scores are 55/100.


With these scores IE-9 is clearly a failure, specially when current publically available browsers like chrome, safari, opera are scoring 100/100 and Firefox scored 94/100 on my machine.

IE’s present version (IE 8) that is available publically is a failure as per acid tests. Check the screen shot below.

So IE-8 is for sure no where in competition.

To Conclude based on Acid Tests

To conclude I would say, Internet Explorer is a FAILURE even IE 9. Microsoft is just blessed by a fact that most of normal PC users never think of switching their browsers, even some don’t know there are other better browsers available. So that might be the reason why Microsoft is still most widely used web browser with scores of a failure.

What really surprises me most is “How open source and community driven products like WebKit, Firefox beat Microsoft’s web browser in a brutal way, even the latest generation of IE is no where in competition. IE is also not a new Microsoft product, its most experienced browser of all, if I’m not wrong”. Seem Microsoft needs to hire better developers !

April 12, 2010

Fast XML DOM vs XmlDom Benchmarks !

Today I got a nice comment about “Fast XML DOM” script consumption being more of Ron Hess’s “XmlDom.cls”. That surprised me and I thought why don’t give a try and publish the results.

Benchmarking - Fixture

The most important thing to get benchmarking transparent and easy for everybody to reproduce was to search a decently big XML document to perform operations on. For this I decided to pick any public XML Atom feed, and decided to use it from a google code project feed. Here is the link to this xml.

Apart from that, for first round of bench marking, I picked two other criteria’s for benchmarking both the APIs. These are

  • Benchmark#1 - DOM Creation: This operation is pretty heavy as it involves creating DOM structure from a XML string.
  • Benchmark#2 - getElementsByTagName() API Call”: This is pretty popular and nice API to test how well a XML API performs on parsing XML structure to give matching nodes for a name.
  • Benchmark#3 - getElementByTagName() API Call”: This API call is pretty similar to that to the above one. But its performance depends on the way its implemented.

To keep this benchmarking simple and extensive for future a new class “TG_XMLDOM_BenchMarks” has been added to the API. You can check it to see how I am benchmarking.

Benchmark#1 - DOM Creation


INFO|XmlDom.constructor() -> Scripts Used : 4804 ,time consumed : 264
INFO|TG_XmlDom.constructor() -> Scripts Used : 26 ,time consumed : 18

Benchmark#2 - getElementsByTagName API call


INFO|XmlDom.getElementsByTagName() -> Scripts Used : 795 ,time consumed : 28
INFO|TG_XmlDom.getElementsByTagName() -> Scripts Used : 560 ,time consumed : 55

Benchmark#3 - getElementByTagName API call


INFO|XmlDom.getElementByTagName() -> Scripts Used : 798 ,time consumed : 27
INFO|TG_XmlDom.getElementByTagName() -> Scripts Used : 38 ,time consumed : 2

I am glad benchmarking started and resulted well. I will doing more bench marking in coming days. This will give Fast XML DOM users/developers more confidence on the API and will help us figure out more areas for polishing and optimizations.

Fast XML DOM getElementsByTagName Optimized !

Today I did some code optimization, cleanup and refactoring. Result of that was TG_XmlNode.getElementsByTagName() was optimized to consume lesser script statements. I was able to reduce the script consumption upto 50%, by in-lining many statements and adding few checks.

Together with this I added a bench marking class “TG_XMLDOM_BenchMarks.cls”. This can be used to quickly bench mark XmlDom vs Fast Xml DOM on different xml samples.

How to use bench marking

  1. Open “TG_XMLDOM_BenchMarks.cls
  2. Locate static string variable named “XML_URL” to public URL of your XML sample. Together with this, you need to white list domain for this url via “Setup > Security Controls > Remote Site Settings”.
  3. Call  “TG_XMLDOM_BenchMarks.benchmark()” to start benchmarking.
    // Just call this method
  4. Check the debug logs, the results will be logged with Logging Level of INFO. Sample shown below:  
    INFO|XmlDom.constructor() -> Scripts Used : 4804 ,time consumed : 264
    INFO|TG_XmlDom.constructor() -> Scripts Used : 26 ,time consumed : 18


References :
  • SFDC Code share Page
  • Google Code project
  • Quick Start Guide
  • Source Code
  • April 7, 2010

    Steve Gillmor left techcrunch for salesforce !

    Its pretty interesting to see Marc Benioff convinced Steve Gillmor to join Salesforce. It must be hard to convince a extremely popular tech journalist move to a CRM company. Marc did a great job here and its pretty exciting to wait and watch what comes up new after getting Steve in salesforce.

    Though I was little disappointed by the words Techcrunch used for Marc and Steve in this article and video. I think its highly un-professional act from a giant like Techcrunch, they sound like a Kid crying and complaining after loosing a toy.

    Lucrative offer can be a big reason, but still there should be something more interesting and lucrative in other sense that made Steve join salesforce. I appreciate generosity of Steve, he will still write an article/week for Techcrunch.

    In end I would just say, Marc did a brilliant job and awesome addition to the sfdc team. I am excited about this and waiting for some more cool stuff to come.

    April 3, 2010

    Fast XML DOM featured in SFDC March 2010’s Newsletter !

    My Open Source SFDC Endeavor "Fast Apex XML DOM" was featured by SFDC March 2010 Developer Newsletter.

    Thanks to Salesforce team for picking this project. Its really a good motivation to do more open source on CODE SHARE !

    Chatter is on my hit list now, have few ideas under development. Will update you all soon.