The Module Pattern

Posted in development by Kris Gray on April 26th, 2011

Establish a private context to run your code in and returns the result.

  1. (function() {
  3. /* Code Here */
  5. })();

Some features of this pattern.

Importing variables to act as local.

  1. (function(win, doc, accent){
  2.     // Same as Sfdc.log();
  3.     accent.log(win.location.href);
  4. })(window, document, Sfdc);

This has the benefit of referencing each parameter as a local which improves performance.
Also the input can be changed while the implementation inside the module wouldn’t need to be touched.

Return a result.

  1. var myAppsAPI = (function() {
  2.     // These two functions cannot be called from outside this module.
  3.     // And you won't have name collisions incase someone else decides to
  4.     //   create a drawTo() global function later.
  5.     function init() {};
  6.     function drawTo() {};
  8.     // then someone else could call your api in this fashion.
  9.     // myAppsAPI.draw(Sfdc.get("elementId"));
  10.     return {
  11.         draw: function(div){
  12.             init();
  13.             drawTo(div);
  14.         }
  15.     }
  16. })();
No comments

YUI Test waitFor function

Posted in development by Kris Gray on March 31st, 2011

If you’ve used selenium, you know that you can wait for a condition to be true before resuming the test. It would typically look like this.

  1. clickButton("id='submit'");
  3. waitForSuccessMessage();
  5. assertSomething();

Though when I went and implemented the JavaScript testing framework for, I was dismayed to see this type of functionality missing. Instead all you got whats a pre-defined wait interval. Besides the additional time this takes for your test to run, it really leads to flappiness.

Flappiness being an internal term indicating a test that fails randomly. These being the worst type of test failures ever. Did the environment have a problem? Did another test not clean up after its self? With a predefined wait based on time, its most likely that your action just didn’t happen in time this one instance.

So being able to wait for a condition to be true would be really nice. Here’s the function I wrote internally.

  1. // We have some wrapping logic which makes this sensible,
  2. // though we really should attach to the prototype at some point.
  3. var testCase = new Y.Test.Case(config);
  4. testCase.waitFor = function(waitTest, resumeFunction, timeout, msg) {
  5.             // Run the test every 20ms's till the timeout has been hit.
  6.             var test = this;
  7.             var flag = false;
  8.             var timeoutId = null;
  9.             // See if we should resume after 20ms
  10.             timeoutId = setTimeout(testWait, 20);
  11.             this.wait(function() {
  12.        || "Should not have hit the full wait timeout.");
  13.             }, timeout);
  14.             // What happens if the wait fires and then testWait fires?
  15.             function testWait() {
  16.                 if ( {
  17.                     clearTimeout(timeoutId);
  18.                     return test.resume(resumeFunction);
  19.                 }
  20.                 // Try again here in a sec.
  21.                 timeoutId = setTimeout(testWait, 20);
  22.             }
  23.         };

And for an example of how to use it, here’s the test case I wrote for it.

  1. // Sfdc.Test.Case is a wrapper for the YUI test case.
  2. // We did that to ensure we weren't married to the YUI API.
  3. var tests = new Sfdc.Test.Case({
  4.     name: "JSTest Tests",
  6.     testWaitFor: function() {
  7.         var testFlag = false;
  9.         // In one second the testFlag should be set to true
  10.         setTimeout(function(){ testFlag = true; }, 200);
  12.         function resumeFunction() {
  13.             Sfdc.Test.Assert.isTrue(testFlag, "The test flag should have been set to true after 200ms.");
  14.         }
  16.         function waitForCondition() {
  17.             return testFlag === true;
  18.         }
  20.         this.waitFor(waitForCondition, resumeFunction, 3000, "Shouldn't have waited the full timeout.");
  22.     }  
  23. });

As always comments and thoughts welcome.

No comments

Articles on JavaScript Error objects

Posted in development by Kris Gray on January 11th, 2011

I’m working on the JS Framework for and thought it would be beneficial to have a robust Errors system. So I went looking for some information on what native support JS already provides.

These two articles were very handy.

If I come up with anything fancy in my own implementation, I’ll see about sharing.

No comments

Life of an enterprise UI developer

Posted in development by Kris Gray on December 29th, 2010

Of all the posts and topics I read on the internet, very few of them pertain to the dicsipline of Enterprise Software Developer. Obviously the Steven Souders books are great, and so is the YUI theater. But when it comes to being a solid UI developer at a company like, what is life like?

Living in a Java World

At larger companies, its likely that the majority of the business logic will be on the server. Because of that, a large majority of the developers in the company will specialize in the backend. You’ll have those who specialize in the front end as well, and those who are balanced in each to varying degrees of skill.

With such a make-up of skills, you’ll always be battling those developers who write less then perfect code, and aren’t aware of optimal practices for developing in the browser environment.

Complexity of the System

In a system with a very large code base and product set, you’ll generally have bits of common functionality, but you’ll also have one offs that have completely different UI’s. For instance in Salesforce we have common detail and edit pages, list views, and our Chatter components. These can all be fit into a common UI framework, but we also have things like dashboard builders, page layout editors and event schedulers.

These complicated projects are usually where provided UI API start to break down, the knowledge of the general developers is stressed and UI resources are sought for. As a UI developer its a good situation for you as your generally in high demand. Though as the UI expert on the team, you have the responsibility of not just developing a great product, but you’ll need to ensure that any framework for the company is extended to support your new features and that its all maintainable.

This seems common sense, but to often the UI is considered an add on layer. Something thats added at the end to make the feature either pretty or cool.


This is the big difference between the awesome stuff I’m reading about and what I get to use day to day. For a system like ours here at Salesforce we have a policy of supporting the last 2 versions of IE. We do support the other browser vendors, but as they continually update their browser versions we don’t care so much about anything but the current version. Even though we say we only support the last two versions of IE (8 and 7), we have a few reasons we can’t totally ignore IE6, so essentially we need to support IE back to 6.

With that in mind, most of the capabilities of the HTML5 feature set are off limits. We do use things like CSS rounded corners in W3C complaint browsers, and accept square corners in IE, but thats an easy downgrade. For something like css animations, or postMessage we would need to do a more complicated downgrade and when you need to write something twice it doesn’t seem cost efficient to use the newer features.

In addition to not being able to use cutting edge technologies, you need to be able to program for those lower level browsers. You need to know which CSS selectors you can use if your programming for IE6, DOM inconsistencies in IE6 vs IE7 vs Google Chrome.

Everything Else

The life of a UI developer in a company like Salesforce is really wonderful. I’m really enjoying it, and you have the ability to do things on a scale much larger then most sites. But I want to focus on noting some of the activities unique to enterprise UI development. I know its fruitless to note, but if your curious about anything please ask. Its fun to share.

No comments

Fantastic video on Software Engineering

Posted in development by Kris Gray on December 28th, 2010

If your not following @dalmaer you are really missing out. I feel like I can stay up to date with my field of JavaScript development by simply following Dion. Something he posted a few days ago was this video that he called must watch, and I totally agree. It really redefines a few common perceptions that I’ve had ever since I’ve been programming.

Real Software Engineering – Glenn Vanderburg from Engine Yard on Vimeo.

Update: This second video has been posted as a great follow up video.

No comments

Next Page »