The Source for Java Technology Collaboration
User: Password:



Tom White

Tom White's Blog

Good Behaviour

Posted by tomwhite on July 19, 2005 at 02:00 PM | Comments (5)

One of the things that writing Object Oriented systems encourages you to consider is: what is the responsibility of each class in the system? For example, the Model-View-Controller pattern separates responsibility for the user model, the user interface, and the control logic into three classes. So far, so old hat. Well, perhaps not in the world of Web Development. While AJAX sets the world alight, there is a related re-awakening in JavaScript's relation to (X)HTML and CSS.

It may seem obvious that HTML is the model, CSS the view, and JavaScript the controller, but how many times have you seen this kind of mess?

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html
     PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
  <head>
    <title>Behaviour demo</title>
  </head>
  <body onload="document.getElementById('textbox').focus(); return false;">
    <form id="form" action="results.html" method="get">
      <p>
        <input type="text" id="textbox" name="query" />
        <input type="submit" id="submit" value="Go"
          onclick="this.value='Searching...'; document.getElementById('form').submit();" />
      </p>
    </form>
  </body>
</html>
    
While we're all carefully making sure the server-side stuff is all Model 2 compliant, we're churning out tangled up code at the web layer. Those onload and onclick attributes really stick out. It feels wrong, but we haven't been sure how to fix it.

But now, a slew of articles and blogs are defining a new set of best practices, overturning old assumptions such as JavaScript necessarily hinders accessibility. From a practical point of view, Ben Nolan's Behaviour may be all you need. It allows you to inject unobtrusive JavaScript behaviour to inert HTML. For instance, the previous JavaScript is taken out of the HTML...

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html
     PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
  <head>
    <title>Behaviour demo</title>
    <script type="text/javascript" src="behaviour.js"></script>
    <script type="text/javascript" src="init.js"></script>
  </head>
  <body>
    <form id="form" action="results.html" method="get">
      <p>
        <input type="text" id="textbox" name="query" />
        <input type="submit" id="submit" value="Go" />
      </p>
    </form>
  </body>
</html>
    

... and applied independently using CSS selectors in init.js: (behaviour.js is the library file.)

Behaviour.addLoadEvent (
  function() {
    document.getElementById('textbox').focus();
  }
);

var rules = {
  '#submit' : function(element) {
    element.onclick = function() {
      this.value='Searching...';
      document.getElementById('form').submit();
    }
  }
};

Behaviour.register(rules);
    

The '#submit' string selects the submit button by ID and wires up its onclick event.

There's way more to explore on the aforementioned sites, but I'm already beginning to feel like a better web citizen. Let's hope it finds its way into some of the Java AJAX kits, such as the Java BluePrints Solutions Catalog.


Bookmark blog post: del.icio.us del.icio.us Digg Digg DZone DZone Furl Furl Reddit Reddit
Comments
Comments are listed in date ascending order (oldest first) | Post Comment

  • Tom,
    Nice blog.
    Do you have any "best practices" suggestions for JSF components that generate JavaScript?

    --JohnR

    Posted by: johnreynolds on July 19, 2005 at 02:11 PM

  • Nice, I've been trying to push this style of JavaScript use within the JSF EG and the JavaServer Faces Reference Implementation. I bantered on it quite a bit in Will Iverson's blog too :-)

    Posted by: jhook on July 19, 2005 at 02:24 PM


  • I've been doing web development for a few months now. But I fail to see how assigning those Javascript event handlers in the HTML markup is worse than putting it in a separate file.


    It's very convenient for someone who reads it later to find out what the behaviour of certain links/buttons on the HTML page are, rather than looking them up by ids or classes in another file, and you can never be sure what *any* piece of markup does, because the Javascript could be acting on it in all kinds of strange ways.


    I might be wrong, but I guess this is how events are attached to UI objects in desktop GUI programming too, right?

    Posted by: pramodbiligiri on July 21, 2005 at 02:28 AM

  • John,

    Thanks for your comment. I think the best practices are well described by Bobby van der Sluis, but a good start would be to keep the JavaScript separate (possibly using something like Behaviour), and make it unobtrusive (so in most cases the page works without it).

    Tom

    Posted by: tomwhite on July 21, 2005 at 03:00 PM

  • Hi pramodbiligiri,
    I think putting JavaScript event handlers in the HTML is a bit like putting Java code into JSPs, it's probably OK in moderation but it quickly gets out of hand.
    Separating out your JavaScript means you might even unit test it too.

    Tom

    Posted by: tomwhite on July 21, 2005 at 03:18 PM





Powered by
Movable Type 3.01D
 Feed java.net RSS Feeds