jQuery Templating in the HomeTab.

Andrew Sutherland 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 
original code.

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 
fair game.

- 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...
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20100609/6b81b6b8/attachment.html>

More information about the tb-planning mailing list