W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2011

Re: Model-driven Views

From: Alex Russell <slightlyoff@google.com>
Date: Thu, 28 Apr 2011 13:41:21 +0100
Message-ID: <BANLkTimXS1YEHdtTwWfBbrKLOXkGmCh5Kw@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: Boris Zbarsky <bzbarsky@mit.edu>, public-webapps@w3.org
On Tue, Apr 26, 2011 at 7:32 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> On Mon, Apr 25, 2011 at 9:14 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
>> On 4/22/11 8:35 PM, Rafael Weinstein wrote:
>>> Myself and a few other chromium folks have been working on a design
>>> for a formalized separation between View and Model in the browser,
>>> with needs of web applications being the primary motivator.
>>> Our ideas are implemented as an experimental Javascript library:
>>> https://code.google.com/p/mdv/ and the basic design is described here:
>>> http://mdv.googlecode.com/svn/trunk/docs/design_intro.html.
>> The interesting thing to me is that the DOM is what's meant to be the model
>> originally, as far as I can tell, with the CSS presentation being the
>> view....
>> I guess we ended up with too much view leakage through the model so we're
>> adding another layer of model, eh?
> There's always multiple layers of model in any non-trivial system.  ^_^
> In this case, the original "DOM as model" is valid in the sense of the
> page as a more-or-less static document, where it's the canonical
> source of information.  With an app, though, the data canonically
> lives in Javascript, with the DOM being relegated to being used to
> display the data and allow user interaction.  MDV is one possibility
> for making this relationship cleaner and simpler.

Right. DOM-as-model works here in the sense that if you consider
existing DOM elements to be participants in a hidden (un-exposed,
non-extensible) model, then this is simply a way of using the DOM
hierarchy to make that other "model" axis available, extensible, and
pluggable. MDV still needs a little help in the areas where existing
HTML is strongest as a model (relationship to forms, etc.), but it's
already close enough that the "value" properties of form elements make
sense when bound.

Teasing out how conjoined things have become in HTML/DOM has been
difficult so far, not least of all because DOM fails to make clear how
attributes, properties, and serialization are meant to behave WRT the
"model" of some chunk of markup/DOM.

Received on Thursday, 28 April 2011 12:42:15 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:31 UTC