Ok, so you probably know that Javascript like most other programming languages treats “0″ as false and any other numerical value as true in logic statements. Usually, this is sufficient, unfortunately, sometimes, you need a bit more consistent behavior. For example, ( 2 && 3 && true ) = 2.

Luckily there is a simple fix. Since, ! only operates on boolean data. !(0) is true and !( any other non-null value is false). Therefore, !! returns the boolean value of the original expression.

Another way of coding it, would be “Boolean ( expression );” and directly casting the expression to a Boolean. All things being equal, this would honestly be my preferred way of doing it. After all, legibility in code is one of the utmost considerations for most development, but since bandwidth is also a major consideration in javascript and !! is reasonably intuitive, I personally use it wherever necessary.

Organizational standards are wonderful things.  They enforce consistency, help insure institutional competence and can dramatically reduce the learning curve to get additional staff up to speed on a project.  At the same time, in the world of AJAX standards can be too slow to adapt to a constantly changing landscape.  How do you strike a balance between flexibility and consistency?

 Project Specific Framework Selection

This is one of the most common approaches and is definitely the most flexible.  Project specific standards basically let the needs of a given project describe the choice of frameworks.  A project needing lots of animation and color manipulation may be built using mootools, a complex RIA may be built using dojo & a simpler project may use prototype or jQuery.  The problem with this approach is the frequent need to learn new API’s & potential to develop overly superficial knowledge of toolkits that may lead to unnecessarily cumbersome solutions.

Selection of Approved Frameworks

A step beyond project specific framework selection is the adoption of 2 – 4 approved frameworks within an organization.  In this arrangement, you try to achieve a balance between project appropriateness and standardization.  Usually the frameworks are chosen to accommodate different scales of projects.  A natural breakdown is the use of prototype & scriptaculous where scriptaculous may not be used in every project.  Another breakdown may combine a simple framework like prototype with a RIA platform like Dojo & an intermediate toolkit like jQuery.  In any event, it’s usually a good idea to pick platforms with similar coding styles & api’s to maximize the transference of skills between projects.

Standardizing on a Single Framework

This is definitely a popular approach and prevents any problems with developers needing to relearn things to get up to speed on different projects. Unfortunately, it’s a very high risk approach as toolkits frequently aren’t optimal for every project (e.g. dojo for a brochureware site and prototype for a webmail client).  There’s also the unfortunate possibility of a framework transitioning to an inappropriate licensing model or being abandoned as well.

Standardized Coding Practices

This is a strategy that can be adopted independent of your framework strategy.  basically, since so many of the various frameworks share constructs and they are all based on javascript.   Adopting a set of coding standards can dramatically simplify collaborative development.  Some of the strategies to consider are:

• Standardized Naming Conventions (camelcase, underscore etc.)
• Standardized File Names
• Standardized Function Names
• Comment Formating
• Chaining limits

We’ll discus coding standards more in the future, but since I’ve had several recent discussions on adopting a standard for my organization.  I thought I’d share some of our thoughts with you.

Here’s a great resource for load balancing AJAX applications. Unlike most load balancing strategies.  This one outsources some of the responsibility for balancing to an AJAX client to reduce costs and increase availability.

 http://www.digital-web.com/articles/client_side_load_balancing/

Prototype 1.6 is fast approaching and we’re already seeing loads of developers adopting the update in projects.  As this tutorial shows, The improvements to Class & inheritance in are truly compelling reasons to jump.

Prototype 1.6 Inheritance tutorial via Ajaxian

Menu widgets: Every toolkit’s got one or more and they sure are easy to use & impressive so the temptation is there to just slap them everywhere. After all, you’re already pushing the toolkit to the client anyway, why not make the most of it.

Before you do, tho I encourage you to consider the following & ask yourself if the javascript solution is really appropriate.

The Good: Reasons to use Javascript Menus

Event Handling.

The biggest reason to use a frameworks menu system is event handling, plain and simple. If you have built an ajax ap that utilizes centralized event brokering. A dynamic menu is all but a necessity for maintainable code & consistent user experience. That said, if the menu doesn’t need to be integrated with the scripts on the page (e.g. A site wide navbar), a dynamic menu is likely superfluous.

Branding.

Lets face it, those slick menus with animated effects are damn sexy. Used effectively, they can really help you capture an audience & encourage a greater depth of exploration by visitors in even the simplest of brochureware sites. Even better, since the menus can be built from <li> elements they provide excellent accessibility.

The Bad: Reasons to Avoid Javascript Menus

Reduced Accessibility

JAWS especially doesn’t deal well with DOM elements created on the client side. While there are many improvements in accessibility that can come from javascript frameworks (improved tab order, shortcut keys, etc). Those all require an investment in time and energy at setup. These allowances, however, do not fully address the issue of users on reduced capability devices or reliably interface with legacy accessibility tools.

Rendering Overhead

Any dynamically generated menu will add to the initial rendering time of the page. While this may not be an issue on a modern machine running the latest release of an A level browser. Performance hits can be quite dramatic on a machine loaded down with spyware, vintage hardware or other sub-optimal deployment environments.

Visual Noise.

This goes without saying, KISS is one of the primary rules of interface design. A big fancy menu will likely call attention to itself at the expense of other content. After all, what’s going to bring more value to the site and project a slick menu, or quality, fast loading content.

Page Complexity

KISS applies to markup too. It’s a simple fact that the more complex the code, the more opportunities for bugs to slow down the development process. More significantly, the more complex the code, the longer it takes to grok it again when it comes time to make revisions.

I realize that many of these widgets require little or no markup, so the complexity issue can be a mute point in terms of markup. The big risk is of course that the code you use will be deprecated or outright removed from the next release of the framework.

The Superfluous:

This article was inspired by a recent discussion with a fellow developer. He spent 2 days struggling to integrate a pretty slick fish eye menu into the navbar of a website. While the comp’s of the bar looked great & everything was functioning well. The finished site seemed to lack something. It turns out that so many concessions had been made in the design to accommodate the menu’s space & bandwidth requirements. That the entire rest of the project was lackluster for better or worse. Don’t let this happen to you.

Remember, menu’s are not the value added prospect of any site. They are there to make it easy for our users to find the content & navigate.

This has been out there for quite a while now, but I thought it should be included in the bestiary out of completeness.

http://clientside.cnet.com

Building a Modal Filtering List with YUI

In this tutorial we will build a simple form and embed it in a modal panel.

Building the form
There are two approaches we could take towards building the form : dynamic or static. A dynamically loaded interface is built by the javascript executed on page load, a static interface lurks hidden inside the html source and is displayed when needed. For the sake of simplicity, we will be using a static interface in this tutorial.

Our form is quite simple. It consists of 3 tiers of options and a submit button:

<div id="filterpanelform" style="display:none">
<fieldset><legend>Type</legend>
<input name="type" value="berry" type="checkbox">Berry
<input name="type" value="citrus" type="checkbox">Citrus
<input name="type"value="drupe" type="checkbox">Drupe
<input name="type" value="Melon" type="checkbox">Melon
</fieldset>

<fieldset><legend> Size </legend>
<input name="size" value="small" type="checkbox">Small
<input name="size" value="medium" type="checkbox">Medium
<input name="size" value="large" type="checkbox">Large
</fieldset>

<fieldset><legend> Color </legend>
<input name="color" value="red" type="checkbox">Red
<input name="color" value="orange" type="checkbox">Orange
<input name="color" value="yellow" type="checkbox">Yellow
<input name="color" value="green" type="checkbox">Green
<input name="color" value="purple" type="checkbox">Purple
<input name="color" value="pink" type="checkbox">Pink
</fieldset>

<button value="Filter" name="doFilter" type="button"id="doFilter">Filter</button>
</div>

Notice the style=”display:none;” on the containing div? This is to hide the contents from view until our user calls the modal dialog.

Building the Modal Interface

Now we need to build a YUI panel to contain the filtering interface. Unlike the form elements, the panel we will build dynamically. The panel will be created on page load, but will remain hidden until called for.

// Instantiate a Panel from script
YAHOO.example.container.FormPanel = new YAHOO.widget.Panel("formPanel", { width:"320px", visible:false, draggable:true, close:true} );
YAHOO.example.container.FormPanel.setHeader("Form Panel");

//populate the panel with the form we've hidden in the HTML
YAHOO.example.container.FormPanel.setBody( document.getElementById("filterpanelform").innerHTML );

YAHOO.example.container.FormPanel.render("container");

Here’s a tip for all you Blueprint CSS users.  If you want to extend a background into the margin beyond a column, apply the first & last classes to the column.  Even if it’s not the first column in a row, it will extend the div 10 px into the gutter between columns.