Kris "Justise" Gray

The Module Pattern

Kris Gray — Wed, 27 Apr 2011 05:19:11 +0000

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

PLAIN TEXT

JavaScript:

(function() {
/* Code Here */
})();

Some features of this pattern.

Importing variables to act as local.

PLAIN TEXT

JavaScript:

(function(win, doc, accent){
// Same as Sfdc.log();
accent.log(win.location.href);
})(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.

PLAIN TEXT

JavaScript:

var myAppsAPI = (function() {
// These two functions cannot be called from outside this module.
// And you won't have name collisions incase someone else decides to
// create a drawTo() global function later.
function init() {};
function drawTo() {};
// then someone else could call your api in this fashion.
// myAppsAPI.draw(Sfdc.get("elementId"));
return {
draw: function(div){
init();
drawTo(div);
}
}
})();

YUI Test waitFor function

Kris Gray — Thu, 31 Mar 2011 15:42:51 +0000

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.

PLAIN TEXT

JAVA:

clickButton("id='submit'");
waitForSuccessMessage();
assertSomething();

Though when I went and implemented the JavaScript testing framework for Salesforce.com, 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.

PLAIN TEXT

JavaScript:

// We have some wrapping logic which makes this sensible,
// though we really should attach to the prototype at some point.
var testCase = new Y.Test.Case(config);
testCase.waitFor = function(waitTest, resumeFunction, timeout, msg) {
// Run the test every 20ms's till the timeout has been hit.
var test = this;
var flag = false;
var timeoutId = null;
// See if we should resume after 20ms
timeoutId = setTimeout(testWait, 20);
this.wait(function() {
Y.Test.Assert.fail(msg || "Should not have hit the full wait timeout.");
}, timeout);
// What happens if the wait fires and then testWait fires?
function testWait() {
if (waitTest.call(test)) {
clearTimeout(timeoutId);
return test.resume(resumeFunction);
}
// Try again here in a sec.
timeoutId = setTimeout(testWait, 20);
}
};

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

PLAIN TEXT

JavaScript:

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

As always comments and thoughts welcome.

Articles on JavaScript Error objects

Kris Gray — Tue, 11 Jan 2011 21:17:39 +0000

I'm working on the JS Framework for Salesforce.com 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.

http://www.javascriptkit.com/javatutors/trycatch2.shtml

https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Error

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

Life of an enterprise UI developer

Kris Gray — Thu, 30 Dec 2010 06:29:03 +0000

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 Salesforce.com, 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.

Technologies

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.

Fantastic video on Software Engineering

Kris Gray — Wed, 29 Dec 2010 03:05:43 +0000

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.

Self executing recursive javascript functions

Kris Gray — Mon, 28 Dec 2009 16:59:27 +0000

The title is intimidating, but fear not. This will be short, sweet and probably really easy to understand. And you'll have something to impress me with in interviews if you ever have the pleasure.

Why?

A while back I was writing some code and it turned out it was executed by two different code paths. In one case, the control was all ready and the code needed to be executed right away. In the other case, the control wasn't ready but would be shortly after the window.load event has been fired. Yea I'm not explaining it very well, but really it doesn't matter, lets see code.

Code

PLAIN TEXT

JavaScript:

var isLoaded = false;
(function() {
if(isLoaded) {
document.getElementById("out").innerHTML = "Loaded";
return;
}
// Every 10th of a second call this method again.
document.getElementById("out").innerHTML += "Trying Again
";
setTimeout(arguments.callee, 100);
// If your inside an object, you probably want to keep the THIS pointer.
// For that, you would do the following.
// var self = this, fn = arguments.callee;
// setTimeout(function() { fn.call(self); }, 100);
// The page will be loaded in 3 seconds
// We would probably want to wait for something like
// a DOM event, but its just sample code. So...
setTimeout(function() { isLoaded = true; }, 3000);
})();

We have both techniques of the example in use here, a self executing anonymous function, and a recursive function.

For the self executing anonymous function, we are wrapping our function in parenthesis and then calling it just like any other function.

PLAIN TEXT

JavaScript:

// The anonymous part
(function(){})();

For the self executing part, we get a reference to the function using arguments.callee, which just so happens to be itself. With it we can use a setTimeout to have the function try again later. We could have just kept calling it, but with javascripts single threaded nature, I would think nothing would happen while your calling your function over and over.

PLAIN TEXT

JavaScript:

(function(){
// BAD
// At least in our case. You could have
// a perfectly justifiable reason for doing this
// though.
arguments.callee();
})();

You can see a live example of this code here

IE 6, 7, 8 Only CSS

Kris Gray — Wed, 23 Dec 2009 01:24:41 +0000

Introduction

This topic doesn't really need an introduction, so lets move on!

Options

DOM wrappers using Conditional Comments

This is the technique used by the jQuery UI site. The basics are that if you wrap your entire page in a DIV with the browser version as the class name, you can just add extra rules to your one stylesheet that will get picked up. Then you can use conditional comments to show the appropriate DIV when necessary.

PLAIN TEXT

HTML:

id="home">