However, the introduction of AJAX (WikiPedia:AJAX) has made this strict separation much harder to accomplish. How can a complex, asynchronous web-page be separated into widgets and controllers? Yet without this separation, both widget reuse and automated controller plumbing becomes impossible.
Therefore, be REST-ful (Rest:RestArchitecturalStyle) and steal a trick from CSS: specify what widget an HTML element is representing with the class attribute, and specify what URL the widget should connect to with the id attribute. Write your Javascript to search for classified elements, and to hook up to server-side controllers with simple GETs and PUTs.
By providing, via the HTML, a unique URL for each asynchronous widget to hook to, you allow a single Javascript widget to be reused many times, even on the same page. Writing a controller becomes, once again, a simple task of plumbing widget to model.
[Meatball's caching statistics] demonstrates a simple widget: the two statistics are kept up-to-date asynchronously. The entire HTML to achieve this is:
<span class="synchronized" id="cache-percentage">99.1% (4331)</span>
This "synchronized" widget connects to the [cache-percentage] URL once a minute, and refreshes the information.
(The [Javascript widgets file] achieving this magic is currently 268 lines long, but this includes comments, proper formatting, convenience functions and a whole extra animated widget, not to mention a framework that makes adding new widgets trivial.)
The DojoToolkit? uses the class attribute to transform normal HTML elements into widgets as well. However, it currently requires non-standard attributes to pass parameters into the widgets, breaking HTML compliance. (The current version can use namespaces on these attributes, which is claimed to restore compliance, but the W3C Validator disagrees [1].) The solution above has the nice property of being fully-compliant with the HTML and XHTML standards, as id attributes are allowed on any element.