jQuery Templating in the HomeTab.
asutherland at asutherland.org
Thu Jun 10 03:15:59 UTC 2010
On 06/09/2010 07:08 PM, Blake Winton wrote:
> That sounds intriguing. What sort of things are you thinking of for
> extensibility, and how far away do you think wmsy is from my being
> able to use it?
Previous experience with templating frameworks and extensibility
suggests it is most likely to align with one or more of the following
- Explicit 'mount points' where some context (a list of messages/a
single message, some global helpers, etc.) is provided and your template
can add content.
- Greasemonkey-like fixups where the extension goes in after the
application builds the DOM tree and inserts and/or replaces existing
content with its own.
- Replacing existing templates with extension-provided templates.
My concern with these things is that they tend to greatly bias
extensions in the direction of only being able to cleanly add new
widgets for the cases the initial developers thought of. Attempts to
modify the existing interface end up awkward/brittle and are unlikely to
survive an encounter with another extension. Changes to the interface
will frequently result in the ugly situation of copy-paste-modifying the
Of course, these problems are not limited just to use of templating.
It's primarily a question of factoring; I find the XBL model more likely
to encourage decoupling amenable to extension than templating idioms
which tend to have a more direct-drive approach.
However, XBL1 as it exists in mozilla has several issues, so wmsy tries
to improve on that in the following ways:
- Widget specialization without requiring all object state to be
reflected into the DOM. XBL specifies bindings using CSS. The problem
is that our data does not consist of documents expressed in HTML/XML;
they are JS objects and we reflect the minimum amount of data into the
DOM. Wmsy's widget specification is based on what amounts to very
constrained multiple dispatch where the entire JS object being bound is
- Encourage widget factoring into small, understandable bindings aligned
with the conceptual tasks of the widget. For example, the 'star' on a
message should be its own simple widget. An extension can then easily
replace the boolean star with a 5-star widget without having to
sub-class or monkey-patch a monolithic message binding widget (and
potentially fight other extensions trying to do orthogonal things). I
believe the wacky XBL life-cycle stuff to be a major reason for the
tendency towards large bindings.
- Avoid requiring a lot of extra legwork (or forethought) to make
extensibility practical. For example, since overlays don't work on HTML
pages, it can be hard to even get into the same context as the faceted
search UI let alone extend its giant XBL bindings.
- Provide additional debugging/understanding support. Wmsy widgets are
defined with a (hopefully useful) short description of what they do.
Wmsy widgets are organized into domains. We are able to construct a
graph of how the widgets relate (thanks to the multiple
dispatch/constraint system). Hopefully this will make it easy to write
a 'wmsy explorer' to understand how things currently work and how you
can extend/modify them or debug problems you are having with your extension.
Wmsy also hopes to greatly reduce boilerplate in terms of DOM node
retrieval, localization, and focus handling. Localization remains on
the to-do list and focus handling is temporarily on the back-burner, but
they are important 1.0 features.
I hope to have a usable alpha early next week that I can be confident
about betting the farm on. I've got stuff going on right now which is
looking good, but not enough.
The repo is here if you want to take a gander (lib/wmsy/examples/*-ui.js
is probably the interesting bit):
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the tb-planning