[Tapestry Central] Rethinking Tapestry's approach to JavaScript

[Howard <hl...@gmail.com>]

I've been doing a lot of work for a client using the ExtJS library and
that, combined with many other things I've been looking at, has started
to shift my attitude to the correct approach to client-side JavaScript.
Not a sea change, just a minor adjustment.
Until now, I've had the approach that the page should popup "complete"
and that the JavaScript should only manipulate (or add to) the content
already present. In most cases, such as adding validations to user
input fields, that works fine: you write out the HTML for the field,
remember the id for the field, then add JavaScript that adds event
handlers to the field, finding it by its id.
However, for more complex cases, such as Tapestry's Palette component,
I've been coding like its 2001 for too long.
The Palette component renders out two <select> elements, plus a number
of <divs>, a few buttons, and a chunk of JavaScript to connect it all
together. This means generating a lot of related ids on the server (to
match against the generated HTML markup) and passing those down to the
client.
It's effective but it reflects my relative naivete with JavaScript back
in 2001. It's now so much easier to create a DOM structure on the
client, using any of the major JavaScript libraries. That, in turn,
makes it much more reasonable to just write out an empty <div> element
with an id and install into that empty space all the markup for the
component, generated on the client side. In fact, I envision a version
of the Palette for Tapestry 5.2 that starts as a <select> configured
for multiple selection and is converted on the fly to the familiar
Palette component entirely on the client side ... which means that it
could actually operate in a functional, if limited way, even if
JavaScript is disabled in the client.
ExtJS includes a number of other ideas that are worth thinking about;
I've been very impressed by the concept of a separate controller
hierarchy on the client side (ExtJS calls these "components" as
differentiated from the DOM nodes they create and manage). That's
something that's ad-hoc and inconsistent in Tapestry's client-side
library. I think embracing a similar, more structured approach could
make it easier for Tapestry to embrace even more dynamic Ajax behavior.

--
Posted By Howard to Tapestry Central at 11/07/2009 09:37:00 AM