Saturday, February 2, 2008

Dojo and Code Separation

I remember my first foray into Dynamic HTML and heavy duty JavaScript. It wasn't making a ball roll across the browser or drag-and-drop tic-tac-toe. We had a real problem.

The company I was working for had a huge catalog. The items were grouped into over 1,000 categories, which rolled up into about 100 mid-level categories, and 10 top-level. We wanted a catalog search where people could ask for parts at any level. Modeling the top and mid-level groups as combo boxes - no problem. The bottom-level ones were a problem -nobody wanted to scroll through 1,000 categories.

Our idea was to make the combo boxes hierarchical. I'm gonna change the items here to protect the innocent, but let's say someone wanted to search Lemon Lime Soft Drinks. They would choose Beverages from the first combo box. The second combo box would narrow down to Beverage choices: Water, Juice, Soft Drinks. Choosing Soft Drinks would constrain the third combo box to Cola, Root Beer, Lemon-Lime, etc. So rather than searching through all 1,000 categories of food, they'd have only about 10 choices. Fair enough. That means we have to remove choices from the other two boxes.

To dynamically add and remove choices, the page needed to load all the top, middle and bottom categories into the page (there was no Ajax back then!) I ended up having to mix JSP and JavaScript like this:


<script>
var c=[];
<% for (c in categories) { %>
c[i++] = <%= c %>;
<% } %>
</script>


Ugggg .... leee. Mixing two languages caused us no end of trouble - for example, what is the relationship between the JavaScript c and the Java c above? (Answer: none). We were forever mixing up syntax. This bilingualism is as annoying in code as it is in "artsy" novels.

This problem is endemic to all server language/client language mixtures, be it JSP+JavaScript or PHP+Silverlight or whatever. The more rich we wanted to get on the browser side (which our customers were pushing), the more problematic the mixture becomes. And Ajax? That made the problem worse.

Then there's the Dojo Way. And by "Way", I mean a paradigm shift - so get ready for some out-of-the-box thinking. To rid ourselves of the mixture, we must rid ourselves of the server-side language. Do it all in JavaScript. In MVC parlance, keep the model on the server and put the view and controller on the client. This looks a lot like Visual Basic, right?

But isn't JavaScript a kiddie language? How can it possibly compete with PHP, ASP and Java? Turns out, it can. Very adeptly. And hence Dojo, a JavaScript-based toolkit, makes it an easy process. So stay tuned!

No comments: