Today I’m going to start a three part tutorial in implementing a custom datagrid with prototype & scriptaculous. In part 1 we’ll explore the html & css underlying the widget. Parts 2 & 3 will look at interactivity and legacy browser support (IE 6).

Disclaimer: this project is designed to work on IE 7 and later. It will not render properly on IE 6. We will look into that more with part 3.

So it starts with a table. Tables are much maligned nowadays. The focus is on semantic markup and creative uses of <div> and <span>. In the energy behind css layouts over the past few years, the new markup elements available to the venerable table have been slightly overlooked. Sure the reign of table based layouts is over, but tables are now able to display data more semantically and style it more simply than ever before.

Here’s a traditional HTML table to start from.

<table>
<tr><td> Item Number</td><td>Description</td><td>Qty</td><td>Unit Price</td><td>Total Price</td></tr>
<tr><td>0023</td><td> Apples</td><td>3</td><td>.56</td><td>1.68</td></tr>
<tr><td>0057</td><td> Pears</td><td>13</td><td>.74</td><td>9.62</td></tr>
<tr><td>0137</td><td> Bananas</td><td>8</td><td>.31</td><td>2.48</td></tr>
<tr><td>0587</td><td> Kumquats</td><td>17</td><td>.26</td><td>4.42</td></tr>
<tr><td>0054</td><td> Oranges</td><td>3</td><td>.45</td><td>1.35</td></tr>
<tr><td></td><td>Total</td><td>44</td><td></td><td>19.55</td></tr>
</table>

It’s a decent start, but we can do better. First lets separate the body from the head with <thead> & <tbody> tags. We’ll also replace the header cells with <th> tags to denote their importance. We’re also going to add a set of row numbers. We’ll use <th> for these as well to signify that they aren’t really part of the data (note the empty <th/> we added to the header to make everything stay consistent).

<table>
<thead>
<tr><th /><th> Item Number</th><th>Description</th><th>Qty</th><th>Unit Price</th><th>Total Price</th></tr>
</thead><tbody>
<tr><th>1</th><td>0023</td><td> Apples</td><td>3</td><td>.56</td><td>1.68</td></tr>
<tr><th>2</th><td>0057</td><td> Pears</td><td>13</td><td>.74</td><td>9.62</td></tr>
<tr><th>3</th><td>0137</td><td> Bananas</td><td>8</td><td>.31</td><td>2.48</td></tr>
<tr><th>4</th><td>0587</td><td> Kumquats</td><td>17</td><td>.26</td><td>4.42</td></tr>
<tr><th>5</th><td>0054</td><td> Oranges</td><td>3</td><td>.45</td><td>1.35</td></tr>
<tr><td></td><td>Total</td><td>44</td><td></td><td>19.55</td></tr>
</tbody></table>

The <thead> specifies the header content. When printed, a browser should print it on every page the table spans. More importantly for us, it is a unique dom node we can grab for styling instructions. <tbody> works in a similar way, It allows us to break the internals of a table into a set of segments. This will come in handy later. <th> is a different beast entirely. I like to think of it as the ying to <td>’s yang. <th> & <td> are to <table> what <dt> & <dd> are to <dl>: a semantic way to denote name / value pairs.

Now that our table has a header and a body, It’s time to give it a footer. We’ll do this by using the <tfoot> tag.

At first glance, there is visually no difference between the 2nd and 3rd examples. Both of them look identical. The source, tells a different story. In the 3rd example, the footer row is actually ahead of the <tbody> in the source. This is the beauty of <tfoot> It lets us place the footer early in the table and cleanly separate it from the tbody that follows. It also guarantees that the <tfoot> appears last no matter what we append to the table via script.

All of this looks good, except it would be great if the columns were better styled.  The two columns with financial data especially should be aligned left to ensure that the decimal points align.  In a perfect world, we’d be able to do this with column groups, but that’s something for part 2.

I’m a javascript harlot and proud of it.  I espouse no allegiance to any particular framework, widget or philosophy and pride myself n my ability to select the best tools for the job based on a project’s unique constraints.  I find this puts me in a slightly unique position among developers.  I don’t carry the deep and intimate details of the framework in my brain, instead I prefer to maintain a much shallower depth of understanding.  I prefer road maps and traffic advisories to in depth aboriginal understanding.

This is why I was affected so severely by what seems to superficially be a minor inconvenience: the Scriptaculous wiki outage.  Scriptaculous has already lagged behind prototype in its depth of documentation.  This makes sense, after all, much of the heavy lifting and complex API’s are handled by prototype so an extensive documentation isn’t really necessary.  For most developers, a few well executed demo implementations of the key features are all we need to get the job done.  In fact, well executed demo implementations are especially critical for a framework like scriptaculous where many of the key features require complex implementation and are likely to be only used once or twice per project and not necessarily referenced day in and day out as the project comes together.

Last week, I was tasked to work on just such a feature.  We new the type ahead find was straightforward to implement given the Scriptaculous documentation.  We also knew that it was fundamentally gravy.  Sure, the feature was important to the end product and would mean much of the difference between user frustration and adoption, but It was also significantly less important than some other items like successfully storing to the database, authentication and form processing.  In short, we put it off to the end as I’m sure many developers would.

Unfortunately, the documentation was gone when we needed it.  The wiki outage had hosed the Scriptaculous hosted media wiki instance and the page we needed was simply missing from the new system.  During a several minute minor panic we tried the various internet archives and similar sites in a desperate attempt to find a new solution with negligible success.  Eventually we found the documentation we needed.  

To Scriptaculous’s credit it was in a surprisingly logical place and well done.  Turns out that scriptaculous has wonderful self documentation as part of the functional tests / unit tests suite.  These test files provided us with solid demonstrations of features we were looking to use for this project.

There’s no doubt in my mind that a software component’s single biggest asset is its documentation.    This is as much a feature as an ultra-fast query selector or smoothly transitioning widget.  Scriptaculous provides powerful documentation in a slightly unlikely place but doesn’t provide decent bread crumbs to its existence from the frameworks public site. Given the critical nature of such documentation, It would be nice if it integrated in to the public site or atleast minimally referenced as a resource.

I’m always looking for ways to improve my javascript development and after a few weeks of playing, Javascript MVC test looks like it might be one the best tools yet.

We all know the power of testing our code.  A proper suite of unit tests can be among a projects most valuable assets.  They can ensure against the regressions rampant in rapid application development cycles that may not have adequate opportunities for proper QA.  Most importantly, when coupled with continuous integration tools, a comprehensive test suite catches many bugs close to when they are written and when they are easiest to correct.

Historically, testing javascript hasn’t been the most useful or productive of tasks.  The type of data manipulation, object inheritance and communication most conducive to unit testing has been minimized in most javascript applications.  Instead, most javascript is highly event driven and is often loosely tied to any specific server side data model.  Test MVC stands to provide a powerful testing framework for just those tasks we normally use javascript for.

Key Features

• Cross browser¹ support for typical DOM events, like keypress, click, submit, blur, and focus
• Simulate writing text or dragging an element
• Easily simulate AJAX functionality with sample data in fixture files

Let’s face it, prototyping and mock-ups are a pain in the rear. I’m always looking for ways to streamline the early phases of the design process. Today I found one that is simply brilliant.

Meet GUIMags: Simple, whiteboard magnets of common UI components.

Now you can do mockups on the whiteboard with high fidelity symbols that photograph well. Instead of sketching out the entire design for each iteration, you can simply rearrange elements and erase / rewrite labels as you collaboratively work through a design. When you’re done. You can simply take a picture of the whiteboard and start coding your mockup.

You can find GuiMags here:

http://www.guimags.com/index.php

DOMAssitant 2.7 is a solid improvement to the DOMAssistant framework with a clear focus on CSS.

New functions:

• cssSelect
• AJAX
• setStyle
• setErrorHandling
• first

Other Improvements

• Dramatic Improvements to the CSS Selector performance: I personally consider CSS selectors the most important feature of a framework so the dramatic improvements really help sell me the benefits of the 2.7 release.
• Unicode Support.  This can be a really big one for a variety of reasons.  Personally, I think it should be built into all frameworks from day one (It is built into javascript after all).

You can find out more about the new release here:

http://www.robertnyman.com/2008/04/09/domassistant-27-released-better-faster-slimmer-new-features/

pi.debugger is a new debug console that acts as a graceful counterpart to firebug.  I’ve  and Firebug is an awesome tool for debugging, hands down.  Unfortunately, it is Firefox specific and has to be installed on the clients machine.

Firebug lite is great, but it is extremely limited and provides little more than a logging console.  pi.debugger sits somewhere in between.  It’s not as full featured as firebug, but it does provide the ever useful evaluation console as well as a DOM browser.

Check it out here:

http://code.google.com/p/pi-js/

And test drive it here:

http://kodfabrik.com/app/pi.debugger/

Tab Boxes are one of the most ubiquitous and popular of widgets. They pop up in everything from news sites to accounting software and for good reason. After all, tabs are one of the simplest and most efficient ways to cram more into a given block of screen real-estate than would fit otherwise.

Ajax24’s drop tabs replace the normal tab-box behavior concept with a twist. THese tabs pull blocks of content down from a tab bar to make them available and float them above the background content. (think window blinds or drawers as opposed to tabbed sheets of paper). I have a few reservations about the use of a widget with such slightly unconventional behavior. But all in all, the smooth motions of the widget and it’s novelty surely warrant exploration in more playful interfaces.

You can find the widget at

http://www.flash-free.org/en/2008/04/05/e24tabmenu-–-menu-desplegable-ajax/

Firebug and its kin are awesome for debugging javascript, but once our scripts are in the wild we really don’t have any feedback of any kind about the state of the browser.  DamnIT from JupiterIT attempts to alleviate this by providing an automated feedback system for javascript applications.

How it works:

1. A box appears prompting you to describe your most recent actions:
2. One of the following occurs:
   • you type something and click send
   • you click “close”
   • 10 seconds pass with you doing nothing
3. DamnIT emails you the following information:
   • Browser
   • Page
   • HTML Content
   • Description (if you entered one)
   • Error message
   • File name, line number, and stack (if the browser supports them)

On the surface this is an incredible system.  In practice there are a few key issues that I think need addressed before the product is an ideal fit for every situation.  Basically, I have severe reservations about the email only nature of the system and its dependence on central management.  Both of these are key issues when dealing with sensitive information or large volumes of error messages and I’m sure will be addressed with future versions.  I am going to integrate the system into the next release of BLT and will be providing feedback from those efforts in the near future.  In the short term, you can check out DamnIT here:

https://damnit.jupiterit.com 

 As much as I love jQuery, prototype templates have made it into more than one of my projects because of their versatility and ease of use.  They are a capable and amazing tool for formatting and displaying output on the client side and I thought I’d take a few minutes to dive into them.

So what are templates.  In short they are a string with symbols embedded that are replaced at the time of evaluation to create a new string.  For example:

var apple = { fruit: "apple", variety: "honeycrisp" };

var templ = new Template( "My favorite fruit are #{variety} #{apple}s."  );

console.log(  templ.evalaluate( apple ));

>>> My favorite fruit are honeycrisp apples.

This basic example is really all there is to templates.  But, they can be incredibly useful for formatting and displaying JSON data. and repurposing things in universal ways across an app.

It’s been a crazy several months, new town, new job etc…

I’m finally in a position to start posting again, so you can expect semi regular updates from here on.