<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    On 06/09/2010 07:08 PM, Blake Winton wrote:<br>
    <blockquote cite="mid:4C10492E.5010007@mozillamessaging.com"
      type="cite">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?
      <br>
    </blockquote>
    <br>
    Previous experience with templating frameworks and extensibility
    suggests it is most likely to align with one or more of the
    following approaches:<br>
    <br>
    - 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.<br>
    <br>
    - 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.<br>
    <br>
    - Replacing existing templates with extension-provided templates.<br>
    <br>
    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.<br>
    <br>
    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.<br>
    <br>
    However, XBL1 as it exists in mozilla has several issues, so wmsy
    tries to improve on that in the following ways:<br>
    <br>
    - 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.<br>
    <br>
    - 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.<br>
    <br>
    - 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.<br>
    <br>
    - 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.<br>
    <br>
    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.<br>
    <br>
    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.<br>
    <br>
    The repo is here if you want to take a gander
    (lib/wmsy/examples/*-ui.js is probably the interesting bit):<br>
    <meta http-equiv="content-type" content="text/html;
      charset=ISO-8859-1">
    <a href="http://hg.mozilla.org/users/bugmail_asutherland.org/wmsy/">http://hg.mozilla.org/users/bugmail_asutherland.org/wmsy/</a><br>
    <br>
    Andrew<br>
  </body>
</html>