Elliot Swan

Making Code Poetry Part III: Condense Code Open To Multiple Interpretations 9:35 pm

In the last part of this series (sorry about the delay), we’ll be briefly touching on how to keep your code clean from extra markup then diving into multiple interpretations within code.

Keeping That Code Condense

Much like a poet will often attempt to condense a poem to only those perfect words of utmost importance, a careful developer will also often try to use the cleanest code possible, making sure that the best tools used are used for the job.

When XHTML isn’t as condense as it should be, a common problem we’ll see is divitis, shown below for those of you who aren’t familiar with it:

<div id="header">
   <h1><a href="#"></a></h1>
</div>

<div id="sidebar">
   <ul>
       <li><a href="#">Link 1</a></li>
       <li><a href="#">Link 2</a></li>
       <li><a href="#">Link 3</a></li>
   </ul>
</div>

<div id="content">
   <p>Some content...</p>
   <p>More content...</p>
</div>

This could easily be turned into as the following:

<h1><a href="#"></a></h1>

<ul id="sidebar">
   <li><a href="#">Link 1</a></li>
   <li><a href="#">Link 2</a></li>
   <li><a href="#">Link 3</a></li>
</ul>

<div id="content">
   <p>Some content...</p>
   <p>More content...</p>
</div>

Any styles applied to the first example should still be applicable to the second via CSS.

While I gave a simple example of XHTML divitis, the same problem can often be found in CSS, JavaScript, PHP, Perl, Ruby, or any other language. When we condense our code and get rid of anything we don’t need, it allows us to be more efficient and take advantage of what we do have.

Perks include decreased loading time, better readability, and increased coolness factor.

Taking Advantage of Frameworks

One area I often see overlooked is when developers include a framework then don’t effectively use it. Developers often decide to use a library like Prototype just for Script.aculo.us to get some sweet effects and don’t take advantage of all the other tools Prototype gives them. They still do everything the long way, even though they have the tools to do things much faster and more efficiently.

Prototype offers a lot more than a base for Script.aculo.us–if all you want is effects, use something like moo.fx instead. But if you’re including a library, use it and take advantage of the underlying code you’ve included.

So in short, know what’ve got at your fingertips and use it. Otherwise you’re just wasting space.

Multiple Interpretations

Time for the fun stuff. If you remember from Part I of this series, when we were checking Wikipedia for a definition of poetry we came across this little bit:

Poetry’s use of ambiguity, symbolism, irony and other stylistic elements of poetic diction often leaves a poem open to multiple interpretations.

Believe it or not, this is extremely important in programming, especially when developing widgets or plugins that will be released for others to use.

Let’s say we are developing a widget for Prototype/Script.aculo.us users that will let them create a link that when clicked will initiate an AJAX request for a file, then place the returned content in a premade div and toggle that div.

One way of doing it would be to specify a special ID for the link (let’s say, link) and another ID for the div (say, results), then determine a good name for the file that will be retrieved (for this example, we’ll use /files/content.html). Then people using your script will need to create these IDs and the file.

Your script would then look something like this:

Event.observe(window, 'load', init, false);

function scriptInit() {
Event.observe('link', 'click', Script.Ajax, false);
$('link').onclick = function() {return false;} // stop the event, since Safari doesn't support Prototype's Event.stop()
}

var Script = {
   Ajax:   function() {
           var url = '/files/content.html';
           var target = 'results';
           var myAjax = new Ajax.Updater(target, url, {method: 'post', onComplete: this.Complete, evalScripts: true});
   },
   Complete:   function() {
               Effect.BlindDown('results');
   }
}

But what if somebody wants to use your script who has already created and styled this link, has already made a different box to populate, and already has a different file to be called? In order to use your script, this person would be forced to manually open up your JavaScript and change all of that.

And what if they wanted to have several different links all opening different (or perhaps the same) div? It couldn’t be done with the previous code.

So, let’s leave these things open:

var Script = function() { 

   var trigger = null;
   var target = null;
   var file = null;

return {
   init:   function(tr, tar, f) {
           trigger = tr;
           target = tar;
           file = f;

           Event.observe(trigger, 'click', this.ajax, false);
           $(trigger).onclick = function() {return false;}
   },
   ajax:   function(trigger, target, file) {
           var myAjax = new Ajax.Updater(target, file, {method: 'post', onComplete: this.complete, evalScripts: true});
   },
   complete:   function() {
               Effect.BlindDown(target);
   }
};
}();

Whenever a developer wants to take advantage of this widget of ours, they simply have to execute something like the following:

Event.observe(window, 'load', init, false);

function init() {
Script.init('show', 'image', '/files/content.html');
}

So, we see the advantage with this is that our script can be used in multiple ways and contexts–if we wanted, we could use this same script to call several more files by simply calling Script.init() again.

Well, I hope you enjoyed this little series and possibly came away learning something new. And as always, I’d love to hear your thoughts.

If you missed Parts I and II, you can read them here: Making Code Poetry Part I (an introduction to poetry) and Making Code Poetry Part II: Visual Form