Re: Model-driven Views
From: Rafael Weinsteinmailto:rafa...@google.com?Subject=Re%3A%20Model-driven%20Views&In-Reply-To=%253CBANLkTimZcXiO8U8xHg2Y6eT4igixkCiF7w%40mail.gmail.com%253E&References=%253CBANLkTimZcXiO8U8xHg2Y6eT4igixkCiF7w%40mail.gmail.com%253E>> It sounds like the group wants to proceed by looking first at missing primitives. Maciej is right that one of them is the ability to declare inert DOM structures, In XForms we use the /instance/ element to do this. but my feeling is that it's probably best to start with the central problem: -There's no way to observe mutations to JS objects. I'll give some comments on this second question, but first I'll go through how we do "inert DOM structures" using the instance element. Of course, in spec-land we do it by describing the /instance element /and its interactions with expressions referring to it, and with DOM events, but in the context of the current discussion about adding new webapps support, it's important to take a look at how it's achieved in today's client-side implementations of XForms in common desktop browsers. There are two main approaches: The AgenceXML implementation uses an XSLT PI at the top to parse out the XForms namespaced elements, and when xhtml:head/xforms:model/xforms:instance with element content is seen, it's converted into a DOM object. The Ubiquity XForms implementation uses a purely Javascript-based approach to this transformation, without using the XSLT PI, but it suffers the treatment non-HTML elements receive when appearing lexically in the host document DOM. As far as feature definition of the "inert DOM structure" goes, here's a brief overview of how we use instance in XForms, and then I'll segue into how separating data and presentation makes the mutation observation question solvable. Additionally, note that XForms allows for an @src attribute on instance which specifies a resource to be loaded; there's a DOM event which signals that it's time to do this, and the XForms processor responds to that event. Finally, XForms offers a /submission/ element which can submit data from an ID'd instance, and send data from responses back to instances or parts thereof. For example, red 3 Color: Size: Your price: Buy When the page is loaded, the instance XML will get initialized with the data. When the user interacts with the form controls, changes will be commited to the instance data. When the user presses the submit button labeled Buy, the submission will POST the instance data. Since the submission says replace instance, the submitted instance will be replaced. Note that the initial data contains no price, so the output bound to "price" will not display at all; it's considered /irrelevant/. When the response comes back, if it has a price, it will then display, along with its label. Let's say you wanted to split the request and response into two different pieces of XML and not share them in the page. Just add a second instance, and now put ID attributes on the two: red 3 ref="instance('rfq') replace="instance" target="quote" /> Color: Size: Your price: Buy Note the changes in the submission to show that the data from the "rfq" instance and the response goes to "quote." If some sub-part of the instance were to be submitted, it would be done inside that expressions. Now, let's assume that performing a request for a quote is idempotent and has no side effects. REST web architecture would have us use a GET instead of a POST. XForms uses sensible defaults, so the GET will serialize leaf-node data as application/x-www-url-formencoded, so all we need to do is change the method on the submission from POST to GET: red 3 Color: Size: Your price: Buy Let's move the initial order out of the form and into a resource on the server by changing instance to have a src attribute: Color: Size: Your price: Buy where initial-quote.xml has the obvious content, and is served up with an HTTP GET. Let's flesh out the data layer a bit with some datatypes and constraints. Let's say size is an integer and it's constrained to be 0 to 14. We do this declaratively by binding a datatype and a constraint to the size node. Furthermore, let's make sure that both color and size aren't empty with required="true()": required="true()" /> Color: Size: Your price: Buy Now the form won't submit (and if you try will raise an xforms-submit-error DOM event with the context information), and any form controls bound to the invalid nodes will receive xforms-invalid events when the user interacts with them. Furthermore, those controls will also get CSS pseudo-property :invalid. (They're also similarly have :required and xforms-required events). So this interestingly answers Rafael's questions below about mutations. In XForms, the mutations happen to the data model, but the obser
Re: Model-driven Views
On 5/6/11, Rafael Weinstein wrote: > Thanks everyone for your consideration. > > It sounds like the group wants to proceed by looking first at missing > primitives. Missing primitives? What do you mean? -- Garrett
Re: Model-driven Views
Thanks everyone for your consideration. It sounds like the group wants to proceed by looking first at missing primitives. Maciej is right that one of them is the ability to declare inert DOM structures, but my feeling is that it's probably best to start with the central problem: -There's no way to observe mutations to JS objects. Current approaches resort to a number of hacks which create really terrible artifacts in application code. The ECMA Script Proxy mechanism may be the best starting point, but there's a related problem with timing that isn't addressed. I'll start a thread shortly on this problem detailing our best understanding, and make an attempt to loop in library authors to get their view. On Thu, Apr 28, 2011 at 2:02 AM, Maciej Stachowiak wrote: > > On Apr 27, 2011, at 6:46 PM, Rafael Weinstein wrote: > >>> >>> What do you think? >>> >>> - Is this something you'd like to be implemented in the browsers, >> >> Yes. >> >>> and if yes, why? What would be the reasons to not just use script >>> libraries (like your prototype). >> >> FAQ item also coming for this. > > Having heard Rafael's spiel for this previously, I believe there are some things that templating engines want to do, which are hard to do efficiently and conveniently using the existing Web platform. > > However, I think it would be better to add primitives to the Web platform that could be used by the many templating libraries that already exist, at least as a first step: > > - There is a lot of code built using many of the existing templating solutions. If we provide primitives that let those libraries become more efficient, that is a greater immediate payoff than creating a new templating system, where Web apps would have to be rewritten to take advantage. > > - It seems somewhat hubristic to assume that a newly invented templating library is so superior to all the already existing solutions that we should encode its particular design choices into the Web platform immediately. > > - This new templating library doesn't have enough real apps built on it yet to know if it is a good solution to author problems. > > - Creating APIs is best done incrementally. API is forever, on the Web. > > - Looking at the history of querySelector(), I come to the following conclusion: when there are already a lot of library-based solutions to a problem, the best approach is to provide technology that can be used inside those libraries to improve them; this is more valuable than creating an API with a primary goal of direct use. querySelector gets used a lot more via popular JavaScript libraries than directly, and should have paid more attention to that use case in the first place. > > Perhaps there are novel arguments that will dissuade me from this line of thinking, but these are my tentative thoughts. > > Regards, > Maciej > >
Re: Model-driven Views
Rafael, I am co-chair of the W3C Forms Working Group. As Charles McCathieNevile pointed out in this discussion: >It probably makes sense to ask the Forms group as well, given that it >doesn't require much squinting to get to the perspective where you're >pretty much reinventing a wheel they've already got two of. And as Dave Raggett pointed out: >Note that a particularly long standing effort on applying the MVC design >pattern to the Web is XForms where the model is represented as a DOM >tree. We're very interested in continuing this discussion with you. Please see http://www.w3.org/TR/xforms11 for our current W3C Recommendation and http://www.w3.org/MarkUp/Forms/ for our group page with implementation news, courses, etc. You'll find our Working Group has over ten years of W3C Recommendations and many implementations of MVC and declarative, markup-based interfaces to (and extensions of) underlying HTML functionality. We're currently quite interested in promoting declarative interfaces to some of the new functionality that HTML5 is pouring into desktop and mobile browsers, as we have done with existing functionality from the HTML4/XHTML1 series. Additionally, we're working to try to bring forward some of the stagnant XBL2 work in a form that gives the web a markup-based component architecture. Finally, we are interested in your point in [http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/0428.html] that We can create a feature which is "fast by default". Libraries almost never do. The Mozilla implementation of XForms used Mozilla XBL and underlying C++ code (Transformix and others) to provide a fast implementation of XForms. Unfortunately, it was limited to Mozilla. Recently, a cross-browser approach has lately taken hold, and the more recent XSLTForms and Ubiquity Forms projects provide a JavaScript library-based approach to implementing XForms in today's desktop and mobile browsers. We recognize that not everyone wants an MVC and markup based approach to declarative programming, but given that this is your area of interest, we'd be very interested in working with you to help design new APIs for browser features that enable implementations of XForms to be fast, stable, and secure in new desktop and mobile browsers. Upper level libraries could make use of these features to provide convenient interfaces for web authors, and so the lower-level features themselves are free to be designed in a more specific fashion. Limiting what fundamental capabilities are added to those which are necessary for a number of approaches may, and then letting the upper-level implementations provide convenient interfaces may answer Maciej's concern that "API is forever, on the Web" and echo Olli's comment "better to add primitives which allow creating script libraries." (For an example of how we have done this, see XForms submission element with XHR, or XML Events wrapping of DOM Events. ) In particular, we'd love to see support for the shadow-DOM notion from XBL2 so that a component system along the lines of XBL could be developed and written. For XForms, the benefit would be this: a component system would allow developers to implement XForms via expansion into underlying browser facilities dynamically, and would also allow XForms authors to design their own components made up of XForms and other HTML and SVG elements (component widgets, macros, what have you). Since such a component system would be orthogonal, it would be useful to all, whatever form of expression your preference for MVC takes. Thank you, Leigh L. Klotz, Jr. Senior Software Architect Xerox Corporation Co-Chair, W3C Forms Working Group
Re: Model-driven Views
On 5/2/11, Rafael Weinstein wrote: > Apologies. I feel like I have failed to properly contextualize this issue. > > Let me back up and see if I can't help create a different frame of > reference. This email is already too long so I've avoided examples. > Please let me know what isn't apparent and I'll explain further. > > > 1) Imperative templating (JSP, jQuery, Closure, a load of others) is > the problem. Declarative templating (Angular, Knockout, JSTemplate, > Spry) is the solution. > After reading your clarification, I am certainly confused about your proposal, particularly of what exactly the problem is. I thought I understood what you wanted, but now I'm sure I don't. I rather like the proposal format of: Problem: Need a way to do [blah]. [Approach X] works but has [disadvantage A]. [Approach Y] works but has [disadvantage B]. [Proposal] has none of [disadvantages {A, B}]. [Proposed fallback strategy] to use when [proposal] is unsupported. [Failure] situation when [fallback strategy] is not used. -- Garrett
Re: Model-driven Views
Apologies. I feel like I have failed to properly contextualize this issue. Let me back up and see if I can't help create a different frame of reference. This email is already too long so I've avoided examples. Please let me know what isn't apparent and I'll explain further. 1) Imperative templating (JSP, jQuery, Closure, a load of others) is the problem. Declarative templating (Angular, Knockout, JSTemplate, Spry) is the solution. -Imperative approaches reduce to a function that spits out a string containing markup. -They are destructive in updating an existing view. "Re-rendering" trashes transient state and thus they are fundamentally unsuitable for dynamic web applications. -They aren't performant because they require destruction and re-creation of all instances in a collection when any item is added or removed. -Use of innerHTML for parsing tends to create XSS attack surface. 2) There's very little new in our design. This isn't a question of validating a new approach. Its a question of doing the hard work of making a successful pattern fit well into the rest of the web platform. -We've simply taken the basic design aspects of existing declarative approaches and attempted to explain their behavior with respect to the rest of the platform APIs. Further, we've attempted to give the pattern direct support for missing capabilities which currently require fairly ugly hacks. -Declarative approaches are heavily deployment tested and shown to be robust. -Declarative templating is a subset of the expressiveness of imperative. Generally speaking it's the subset that people use. [An imperative->declarative compiler is possible. It would need to enforce certain things. e.g. code blocks must contain balanced HTML, loops must not exit early, conditionals must be deterministic, etc...]. 3) The diversity in templating systems doesn't represent diversity in approaches or semantics. The differences are mostly superficial. The expressive requirements can be summarized quickly: a) Insert, assign (and possibly transform) a data value into an attribute, property or textContent. b) Conditionally include/show a bit of DOM. c) Produce a sub-template once for every item in a collection. d) Sub-iteration support is required e) Recursion (producing unknown depth trees) support is required f) Some mechanism for scoping is specifically required inside iterations, and more generally, so that full paths to data items don't need to be typed. 4) The lack of a standard blocks economies of scale that generally lead to many terrific things I don't have to list for this group, but most importantly: -Automation: Complexity kills. Non-trivial applications need tooling support. The automation and tooling support for Windows, MacOS and even Linux dwarfs that of web applications. Without a standard, there's little chance that we'll get good tools (inspecting/debugging, authoring, validation, optimization) inside or outside the browser. 5) We can create a feature which is "fast by default". Libraries almost never do. -Our design is such that it fully delays all DOM work until the script event exits and then hands the instructions to the renderer as a batch. -UAs try to be lazy about doing work in order to only do expensive things minimally. This is the lazy "nuclear option". All DOM work can be fully lazy. We're hopeful that there are big perf gains to be had here, but experimental implementations are the only way to prove this. -At minimum, the typical case can be assured to only incur one layout/style resolution. 6) Libraries can't hit the latency goals that we'd like to. -Libraries cannot render incrementally during page load. Leaving this to libraries will continue to put apps in the awkward position of *needing* to render on the server first so as to deliver a page that loads above the fold immediately and then precariously bootstrapping back into a proper dynamic separation of view & model. -Wire-bytes are getting cheaper but latency isn't. Loading libraries is a bitter pill to swallow in order to create the basic abstractions you need to improve productivity and scale your application. [http://www.stevesouders.com/blog/2010/07/13/velocity-tcp-and-the-lower-bound-of-web-performance/] 7) Leaving DOM production to libraries worsens the tower of babel problem. -Most JS frameworks make an attempt to be in control of DOM production. The platform needs to be the cop and make the libraries play nice. For example, Angular would like to provide a development methodology but allow jQuery widgets to be used. Both (rightly so, lacking browser support) want to be in control. Chaos ensues. -We can spec the semantics, timing, and lifetime events of DOM production such that it opens the way for libraries to reliably plug in and be more confident that some other library won't break them. XBL is apropos for similar reasons. 8) Script has no ability to expand the declarative semantics of HTML -The operation of web apps is alrea
Re: Model-driven Views
On Sat, 23 Apr 2011 02:35:53 +0200, 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. It's not complete and there are things we're not happy with, but it's self-consistent enough that you can start to imagine what a full design might look like. It looks an *awful* lot like the templating part of Web forms. If you get a copy of Opera 9.5 (we removed the code when it became clear that nobody else would implement in the last 3 years), you can see that in action with the attached code: Remove Move Up Move Down Add That in turn was a pretty straight rip-off from Xforms which allows the same thing with a little more power, and is even closer to what it seems you're looking to do. We hope to get others interested in collecting requirements/use cases and fleshing out a good solution. I used it to create simple tools that created templates, and tools that used templates for collecting information. My first use case was a multilingual international court case (i.e. something that really mattered and not just a test), and the ability to easily generate custom systems was fantastic. I greatly appreciated the ability to have models without needing to use script - as Steven Pemberton says of Xforms, this makes development much faster by reducing complexity in the code, and my experience conincides with that perfectly. While I could readily use scripting to develop the same systems I would expect the work to take longer and be substantially more complex to maintain and debug. FWIW as far as you do make something script-based, I agree with the sentiment expressed that it should work well with existing libraries, helping them to reduce the towe-of-babel problem by converging rather than increasing it by adding yet another set of libraries to the mixture. We're starting the discussion here because a few people in this group from whom we got early feedback felt that it would be most appropriate place It probably makes sense to ask the Forms group as well, given that it doesn't require much squinting to get to the perspective where you're pretty much reinventing a wheel they've already got two of. and, further, that this work bears some relation to XBL. As well, at least conceptually. cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: Model-driven Views
On Apr 28, 2011, at 5:46 AM, Alex Russell wrote: > On Thu, Apr 28, 2011 at 12:09 PM, Maciej Stachowiak wrote: >> >> On Apr 28, 2011, at 2:33 AM, Jonas Sicking wrote: >> >>> >>> I agree with much of this. However it's hard to judge without a bit >>> more meat on it. Do you have any ideas for what such primitives would >>> look like? >> >> That's best discussed in the context of Rafael explaining what limitations >> prevent his proposal from working as well as it could purely as a JS library. > > The goal for this work is explicitly *not* to leave things to > libraries -- I'd like for that not to creep into the discussion as an > assumption or a pre-req. I introduce this not as a pre-req or assumption but rather as my view of the best approach to addressing templating use cases, at least as a first step.I would also like it not to be a pre-req that templating must be addressed by a monolithic solution. But I am willing to hear out arguments for how it is better. > Libraries are expensive, slow, and lead to a tower-of-babel problem. That is all potentially true. But the tower-of-babel problem already exists in this area. Adding a new solution won't make the existing solutions disappear. The best way to mitigate the costs you describe is to provide primitives that enable the existing solutions to improve their quality of implementation. > On the other hand, good layering and the > ability to explain current behavior in terms of fewer, smaller > primitives is desirable, if only to allow libraries to play whatever > role they need to when the high-level MDV system doesn't meet some > particular need. That is a reasonable line of thinking. But in addition to modularity, I would also suggest a particular ordering - first add the right primitives to enable efficient, convenient DOM-based templating, then look for libraries to adopt it and/or promulgate new libraries, and only then standardize the high-level bits if they turn out to be high-value at that point. I had many particular supporting arguments for this approach, which your comments do not address. > >> The one specific thing I recall from a previous discussion of this proposal >> is that a way is needed to have a section of the DOM that is inactive - >> doesn't execute scripts, load anything, play media, etc - so that your >> template pattern can form a DOM but does not have side effects until the >> template is instantiated. > > Right. The contents of the element are in that inactive state. > >> This specific concept has already been discussed on the list, and it seems >> like it would be very much reusable for other DOM-based templating systems, >> if it wasn't tied to a specific model of template instantiation and updates. > > Having it be a separately addressable primitive sounds like a good > thing...perhaps as some new Element type? I'm glad we agree on this aspect. I'm not sure what you mean by new Element type, but nothing prevents us from simply defining a new ordinary element (HTML element or otherwise) that has this semantic. Note that HTML elements generally already have the desired inactive behavior in viewless documents (as created by createDocuemtn or XMLHttpRequest) so an element that introduces such behavior should be quite modest in terms of spec and implementation burden. Regards, Maciej
Re: Model-driven Views
On 04/29/2011 04:11 AM, Garrett Smith wrote: On 4/28/11, Olli Pettay wrote: On 04/28/2011 04:46 AM, Rafael Weinstein wrote: Would be good to know what are the use cases you had in mind. I'm never sure if I'm using the term "use case" correctly =-). Our primary motivator is the needs of web applications, And what are those needs? It is hard to judge the proposal if it is not known what kinds of problems it is trying to solve ;) Create HTML content that gets refreshed, using JSON? That doesn't explain the feature set MDV supports. Why, for example, JSON/Model data can't affect to what kinds of elements the template creates. Or attributes. Why certain functionality is in and other functionality is out. So basically I'd like to see either some requirements document or at least public discussion about the design of the API. -Olli Load chunks of samely structured content on-demand. Sample app I made for bittorrent when applying for a job: http://dhtmlkitchen.com/tmp/bittorrent/ (waste of time, that was). For example of content that gets refreshed, a table refresh widget would update the data in the HTML TABLE by fetchng JSON. Content that is loaded on-demand but reused in a template could be a product-info panel or a tooltip. Each panel is tied to an actuator and is shown with unique data, but it is created from a template that has essentially the same structure.
Re: Model-driven Views
On 4/28/11, Olli Pettay wrote: > On 04/28/2011 04:46 AM, Rafael Weinstein wrote: >>> Would be good to know what are the use cases you had in mind. >> >> I'm never sure if I'm using the term "use case" correctly =-). >> >> Our primary motivator is the needs of web applications, > > > And what are those needs? It is hard to judge the proposal > if it is not known what kinds of problems it is trying to solve ;) > Create HTML content that gets refreshed, using JSON? Load chunks of samely structured content on-demand. Sample app I made for bittorrent when applying for a job: http://dhtmlkitchen.com/tmp/bittorrent/ (waste of time, that was). For example of content that gets refreshed, a table refresh widget would update the data in the HTML TABLE by fetchng JSON. Content that is loaded on-demand but reused in a template could be a product-info panel or a tooltip. Each panel is tied to an actuator and is shown with unique data, but it is created from a template that has essentially the same structure.
Re: Model-driven Views
On 04/28/2011 04:46 AM, Rafael Weinstein wrote: Would be good to know what are the use cases you had in mind. I'm never sure if I'm using the term "use case" correctly =-). Our primary motivator is the needs of web applications, And what are those needs? It is hard to judge the proposal if it is not known what kinds of problems it is trying to solve ;) -Olli
Re: Model-driven Views
On Thu, Apr 28, 2011 at 12:09 PM, Maciej Stachowiak wrote: > > On Apr 28, 2011, at 2:33 AM, Jonas Sicking wrote: > >> On Thu, Apr 28, 2011 at 2:02 AM, Maciej Stachowiak wrote: >>> >>> On Apr 27, 2011, at 6:46 PM, Rafael Weinstein wrote: >>> > > >> >> What do you think? >> > > - Is this something you'd like to be implemented in the browsers, Yes. > and if yes, why? What would be the reasons to not just use script > libraries (like your prototype). FAQ item also coming for this. >>> >>> Having heard Rafael's spiel for this previously, I believe there are some >>> things that templating engines want to do, which are hard to do efficiently >>> and conveniently using the existing Web platform. >>> >>> However, I think it would be better to add primitives to the Web platform >>> that could be used by the many templating libraries that already exist, at >>> least as a first step: >>> >>> - There is a lot of code built using many of the existing templating >>> solutions. If we provide primitives that let those libraries become more >>> efficient, that is a greater immediate payoff than creating a new >>> templating system, where Web apps would have to be rewritten to take >>> advantage. >>> >>> - It seems somewhat hubristic to assume that a newly invented templating >>> library is so superior to all the already existing solutions that we should >>> encode its particular design choices into the Web platform immediately. >>> >>> - This new templating library doesn't have enough real apps built on it yet >>> to know if it is a good solution to author problems. >>> >>> - Creating APIs is best done incrementally. API is forever, on the Web. >>> >>> - Looking at the history of querySelector(), I come to the following >>> conclusion: when there are already a lot of library-based solutions to a >>> problem, the best approach is to provide technology that can be used inside >>> those libraries to improve them; this is more valuable than creating an API >>> with a primary goal of direct use. querySelector gets used a lot more via >>> popular JavaScript libraries than directly, and should have paid more >>> attention to that use case in the first place. >>> >>> Perhaps there are novel arguments that will dissuade me from this line of >>> thinking, but these are my tentative thoughts. >> >> I agree with much of this. However it's hard to judge without a bit >> more meat on it. Do you have any ideas for what such primitives would >> look like? > > That's best discussed in the context of Rafael explaining what limitations > prevent his proposal from working as well as it could purely as a JS library. The goal for this work is explicitly *not* to leave things to libraries -- I'd like for that not to creep into the discussion as an assumption or a pre-req. Libraries are expensive, slow, and lead to a tower-of-babel problem. On the other hand, good layering and the ability to explain current behavior in terms of fewer, smaller primitives is desirable, if only to allow libraries to play whatever role they need to when the high-level MDV system doesn't meet some particular need. > The one specific thing I recall from a previous discussion of this proposal > is that a way is needed to have a section of the DOM that is inactive - > doesn't execute scripts, load anything, play media, etc - so that your > template pattern can form a DOM but does not have side effects until the > template is instantiated. Right. The contents of the element are in that inactive state. > This specific concept has already been discussed on the list, and it seems > like it would be very much reusable for other DOM-based templating systems, > if it wasn't tied to a specific model of template instantiation and updates. Having it be a separately addressable primitive sounds like a good thing...perhaps as some new Element type?
Re: Model-driven Views
On Tue, Apr 26, 2011 at 7:32 AM, Tab Atkins Jr. wrote: > On Mon, Apr 25, 2011 at 9:14 PM, Boris Zbarsky 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. Regards
Re: Model-driven Views
On 04/28/2011 12:02 PM, Maciej Stachowiak wrote: On Apr 27, 2011, at 6:46 PM, Rafael Weinstein wrote: What do you think? - Is this something you'd like to be implemented in the browsers, Yes. and if yes, why? What would be the reasons to not just use script libraries (like your prototype). FAQ item also coming for this. Having heard Rafael's spiel for this previously, I believe there are some things that templating engines want to do, which are hard to do efficiently and conveniently using the existing Web platform. However, I think it would be better to add primitives to the Web platform that could be used by the many templating libraries that already exist, at least as a first step: - There is a lot of code built using many of the existing templating solutions. If we provide primitives that let those libraries become more efficient, that is a greater immediate payoff than creating a new templating system, where Web apps would have to be rewritten to take advantage. - It seems somewhat hubristic to assume that a newly invented templating library is so superior to all the already existing solutions that we should encode its particular design choices into the Web platform immediately. - This new templating library doesn't have enough real apps built on it yet to know if it is a good solution to author problems. - Creating APIs is best done incrementally. API is forever, on the Web. - Looking at the history of querySelector(), I come to the following conclusion: when there are already a lot of library-based solutions to a problem, the best approach is to provide technology that can be used inside those libraries to improve them; this is more valuable than creating an API with a primary goal of direct use. querySelector gets used a lot more via popular JavaScript libraries than directly, and should have paid more attention to that use case in the first place. Perhaps there are novel arguments that will dissuade me from this line of thinking, but these are my tentative thoughts. I agree with you; better to add primitives which allow creating script libraries. -Olli Regards, Maciej
Re: Model-driven Views
On Apr 28, 2011, at 2:33 AM, Jonas Sicking wrote: > On Thu, Apr 28, 2011 at 2:02 AM, Maciej Stachowiak wrote: >> >> On Apr 27, 2011, at 6:46 PM, Rafael Weinstein wrote: >> > > What do you think? > - Is this something you'd like to be implemented in the browsers, >>> >>> Yes. >>> and if yes, why? What would be the reasons to not just use script libraries (like your prototype). >>> >>> FAQ item also coming for this. >> >> Having heard Rafael's spiel for this previously, I believe there are some >> things that templating engines want to do, which are hard to do efficiently >> and conveniently using the existing Web platform. >> >> However, I think it would be better to add primitives to the Web platform >> that could be used by the many templating libraries that already exist, at >> least as a first step: >> >> - There is a lot of code built using many of the existing templating >> solutions. If we provide primitives that let those libraries become more >> efficient, that is a greater immediate payoff than creating a new templating >> system, where Web apps would have to be rewritten to take advantage. >> >> - It seems somewhat hubristic to assume that a newly invented templating >> library is so superior to all the already existing solutions that we should >> encode its particular design choices into the Web platform immediately. >> >> - This new templating library doesn't have enough real apps built on it yet >> to know if it is a good solution to author problems. >> >> - Creating APIs is best done incrementally. API is forever, on the Web. >> >> - Looking at the history of querySelector(), I come to the following >> conclusion: when there are already a lot of library-based solutions to a >> problem, the best approach is to provide technology that can be used inside >> those libraries to improve them; this is more valuable than creating an API >> with a primary goal of direct use. querySelector gets used a lot more via >> popular JavaScript libraries than directly, and should have paid more >> attention to that use case in the first place. >> >> Perhaps there are novel arguments that will dissuade me from this line of >> thinking, but these are my tentative thoughts. > > I agree with much of this. However it's hard to judge without a bit > more meat on it. Do you have any ideas for what such primitives would > look like? That's best discussed in the context of Rafael explaining what limitations prevent his proposal from working as well as it could purely as a JS library. The one specific thing I recall from a previous discussion of this proposal is that a way is needed to have a section of the DOM that is inactive - doesn't execute scripts, load anything, play media, etc - so that your template pattern can form a DOM but does not have side effects until the template is instantiated. This specific concept has already been discussed on the list, and it seems like it would be very much reusable for other DOM-based templating systems, if it wasn't tied to a specific model of template instantiation and updates. Regards, Maciej
Re: Model-driven Views
On Thu, Apr 28, 2011 at 2:02 AM, Maciej Stachowiak wrote: > > On Apr 27, 2011, at 6:46 PM, Rafael Weinstein wrote: > >>> >>> What do you think? >>> >>> - Is this something you'd like to be implemented in the browsers, >> >> Yes. >> >>> and if yes, why? What would be the reasons to not just use script >>> libraries (like your prototype). >> >> FAQ item also coming for this. > > Having heard Rafael's spiel for this previously, I believe there are some > things that templating engines want to do, which are hard to do efficiently > and conveniently using the existing Web platform. > > However, I think it would be better to add primitives to the Web platform > that could be used by the many templating libraries that already exist, at > least as a first step: > > - There is a lot of code built using many of the existing templating > solutions. If we provide primitives that let those libraries become more > efficient, that is a greater immediate payoff than creating a new templating > system, where Web apps would have to be rewritten to take advantage. > > - It seems somewhat hubristic to assume that a newly invented templating > library is so superior to all the already existing solutions that we should > encode its particular design choices into the Web platform immediately. > > - This new templating library doesn't have enough real apps built on it yet > to know if it is a good solution to author problems. > > - Creating APIs is best done incrementally. API is forever, on the Web. > > - Looking at the history of querySelector(), I come to the following > conclusion: when there are already a lot of library-based solutions to a > problem, the best approach is to provide technology that can be used inside > those libraries to improve them; this is more valuable than creating an API > with a primary goal of direct use. querySelector gets used a lot more via > popular JavaScript libraries than directly, and should have paid more > attention to that use case in the first place. > > Perhaps there are novel arguments that will dissuade me from this line of > thinking, but these are my tentative thoughts. I agree with much of this. However it's hard to judge without a bit more meat on it. Do you have any ideas for what such primitives would look like? / Jonas
Re: Model-driven Views
On Apr 27, 2011, at 6:46 PM, Rafael Weinstein wrote: >> >> >>> >>> What do you think? >>> >> >> - Is this something you'd like to be implemented in the browsers, > > Yes. > >> and if yes, why? What would be the reasons to not just use script >> libraries (like your prototype). > > FAQ item also coming for this. Having heard Rafael's spiel for this previously, I believe there are some things that templating engines want to do, which are hard to do efficiently and conveniently using the existing Web platform. However, I think it would be better to add primitives to the Web platform that could be used by the many templating libraries that already exist, at least as a first step: - There is a lot of code built using many of the existing templating solutions. If we provide primitives that let those libraries become more efficient, that is a greater immediate payoff than creating a new templating system, where Web apps would have to be rewritten to take advantage. - It seems somewhat hubristic to assume that a newly invented templating library is so superior to all the already existing solutions that we should encode its particular design choices into the Web platform immediately. - This new templating library doesn't have enough real apps built on it yet to know if it is a good solution to author problems. - Creating APIs is best done incrementally. API is forever, on the Web. - Looking at the history of querySelector(), I come to the following conclusion: when there are already a lot of library-based solutions to a problem, the best approach is to provide technology that can be used inside those libraries to improve them; this is more valuable than creating an API with a primary goal of direct use. querySelector gets used a lot more via popular JavaScript libraries than directly, and should have paid more attention to that use case in the first place. Perhaps there are novel arguments that will dissuade me from this line of thinking, but these are my tentative thoughts. Regards, Maciej
Re: Model-driven Views
Hi Olli, Thanks very much for taking time to read & digest our design. I'm going to use this thread to start a FAQ on our project site. Some of these questions have answers that deserve more detail than is wise to put in an email =-). On Wed, Apr 27, 2011 at 8:33 AM, Olli Pettay wrote: > HI Rafael, > > > few random comments, or mainly just random questions :) > > On 04/23/2011 03:35 AM, 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. It's not >> complete and there are things we're not happy with, but it's >> self-consistent enough that you can start to imagine what a full >> design might look like. >> >> We hope to get others interested in collecting requirements/use cases >> and fleshing out a good solution. > > Would be good to know what are the use cases you had in mind. I'm never sure if I'm using the term "use case" correctly =-). Our primary motivator is the needs of web applications, but if we can create a good solution for more static cases in the process it'll be that much more a win. By "collecting use cases" I was thinking more about specific patterns that emerge in composing views for applications. One very common example is master/detail. > > >> >> We're starting the discussion here because a few people in this group >> from whom we got early feedback felt that it would be most appropriate >> place and, further, that this work bears some relation to XBL. > > Not sure why this had some relation with XBL. Unless you are > planning to put the template based DOM nodes to anonymous DOM. I'm creating a FAQ question for this. Will reply again when its ready. > > >> >> What do you think? >> > > - Is this something you'd like to be implemented in the browsers, Yes. > and if yes, why? What would be the reasons to not just use script > libraries (like your prototype). FAQ item also coming for this. > If the have-to-change-HTML-parser like parts could be removed, > this all feels like something for JS + Proxy objects, just like what > you've done in the prototype. > > - Is there a reason why you have chosen to create yet another > datastorage like object (although your Model is just a kind of > proxy)? Couldn't you reuse for example IndexedDB? > XUL Templates can be bound to sqlite, XML and RDF. The goal isn't to create a storage mechanism, its to free the application from directly manipulating the DOM and allow it to operate on its data. To *say* what it wants to happen to the UI rather than to do it. If JS objects were directly observable, that would be ideal -- but it seems unlikely that runtime implementors will take the perf hit. Allowing bindings to IndexedDB is a cool idea. We should explore that more. In general, there are a number of things we should consider for sourcing data. > > - Model looks in many ways like JS-fied and simplified XForms > model/instance. Have you investigated if there are important use cases > which XForms can handle (because it has more powerful binding > mechanism) but MDV can't? Are there plans to extend I've read the XForms spec, but I don't feel qualified to comment on use cases that it can better handle. It sounds like you might...? ;-) > the "Path language", or ideas how it could be extended? (XForms has > extensions to XPath) > In general I'm not too happy to see yet another > selector/path language. Would be great if some existing one could > be reused. Sure, some parts of the proposed language look quite a bit > like JSON, but there are other parts which are something very > different. The goal wasn't to create a path/selector language. The basic idea is simple JSON dot-notation. The funny syntax you see (../, ./, /) is our solution to three patterns that come up frequently in templating: -You're in an iteration, but you need a value which is "just above your head" (e.g. http://mdv.googlecode.com/svn/trunk/capabilities/path_reference_ancestor.html) -You're down deep in a object graph rendering you're output, but you need a global value. An example might be composing a URL for an application which is versioned. You need to grab a "global" static path and combine it with some local state (e.g. userId). (e.g. https://code.google.com/p/mdv/source/browse/trunk/capabilities/path_reference_root.html) -Needing to refer to *this* value. This happens all the time. (e.g. http://mdv.googlecode.com/svn/trunk/capabilities/path_reference_this.html) We considered several other options and couldn't come up with a better idea. Suggestions very welcome here (and everywhere, in fact). In general, we're not at all wedded to naming or syntax. Its the semantics
Re: Model-driven Views
On Wed, Apr 27, 2011 at 11:47 AM, Olli Pettay wrote: > On 04/27/2011 09:13 PM, Erik Arvidsson wrote: >> 1. We want to be able to contain arbitrary content that is >> used as the content of the instances that are created from it. Now >> assume that the template element contains some active content such as >> , script or simply just an image. We don't want the >> audio to start playing, we don't want the script to run inside the >> template element and we don't want the image to be requested at this >> point. > > works even if it is not in document, and so > does . > But I see the problem you're trying to avoid. Yeah, we basically just want the actual nodes inside of to be "dead", since their only purpose is to be cloned when you create "real" DOM from the template. How precisely this is accomplished is more-or-less irrelevant at this point. ~TJ
Re: Model-driven Views
On 04/27/2011 09:13 PM, Erik Arvidsson wrote: On Wed, Apr 27, 2011 at 08:33, Olli Pettay wrote: Not sure why this had some relation with XBL. Unless you are planning to put the template based DOM nodes to anonymous DOM. The relation to XBL is that XBL has a template element and inside it you can "bind" attributes and content to the host element's attributes and content. We feel that the same concept can be useful outside of XBL and that we would like to provide a more generic solution that something like XBL can then reuse. But the way XBL, at least XBL1 and some-version-of-XBL2, works is quite far away from MDV template. XBL has anonymous content, which causes event handling and styling to work in a bit different way. etc. And also, in MDV iterative template seems to have quite a big role. That is not what XBL is quite for (although one could implement iterative-like XBL widgets). But ok, both have templates which are used to generate some kind of instance. - "Child nodes are not considered to be a part of the DOM. During parsing, they are lifted out..." Huh, you really want to alter HTML parsing? - "If a template element is created via script, any children are removed and attached to the instancePrototype when the template element is attached to a document." What if the template is already in DOM when the new child elements are added. It sounds *very* strange to add new special cases to DOM Core methods. I feel like the document reflects too much what we ended up doing in the prototype. Lets backup and look at the problems we are trying to fix here. 1. We want to be able to contain arbitrary content that is used as the content of the instances that are created from it. Now assume that the template element contains some active content such as , script or simply just an image. We don't want the audio to start playing, we don't want the script to run inside the template element and we don't want the image to be requested at this point. works even if it is not in document, and so does . But I see the problem you're trying to avoid. 3. The last issue we are trying to provide a solution too is with DOM access, specifically with getElementById, querySelector etc. It is highly unlikely that the user wants to get to the content inside the template element. What they usually want is to get access to the template instance. Yes, makes sense. -Olli
Re: Model-driven Views
On Wed, Apr 27, 2011 at 08:33, Olli Pettay wrote: > Not sure why this had some relation with XBL. Unless you are > planning to put the template based DOM nodes to anonymous DOM. The relation to XBL is that XBL has a template element and inside it you can "bind" attributes and content to the host element's attributes and content. We feel that the same concept can be useful outside of XBL and that we would like to provide a more generic solution that something like XBL can then reuse. > - "Child nodes are not considered to be a part of the DOM. During > parsing, they are lifted out..." Huh, you really want to alter HTML > parsing? > > - "If a template element is created via script, any children are > removed and attached to the instancePrototype when the template > element is attached to a document." What if the template is already > in DOM when the new child elements are added. > It sounds *very* strange to add new special cases to DOM Core > methods. I feel like the document reflects too much what we ended up doing in the prototype. Lets backup and look at the problems we are trying to fix here. 1. We want to be able to contain arbitrary content that is used as the content of the instances that are created from it. Now assume that the template element contains some active content such as , script or simply just an image. We don't want the audio to start playing, we don't want the script to run inside the template element and we don't want the image to be requested at this point. 2. We also want to allow place holders to make it easier to write your templates. Before the template content has been instantiated the content is incomplete or invalid. For example img@src might contain a place holder: It is important that we don't try to request "{{data.src}}.png". 3. The last issue we are trying to provide a solution too is with DOM access, specifically with getElementById, querySelector etc. It is highly unlikely that the user wants to get to the content inside the template element. What they usually want is to get access to the template instance. For example: {{ data }} ... document.getElementById('a').model = {data: 'Hello World'}; assertEquals('Hello World', document.getElementById('b').textContent); In the prototype we got around most of these issues by just moving the content DOM out of the template element. An alternative solution would be to treat more like
Re: Model-driven Views
HI Rafael, few random comments, or mainly just random questions :) On 04/23/2011 03:35 AM, 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. It's not complete and there are things we're not happy with, but it's self-consistent enough that you can start to imagine what a full design might look like. We hope to get others interested in collecting requirements/use cases and fleshing out a good solution. Would be good to know what are the use cases you had in mind. We're starting the discussion here because a few people in this group from whom we got early feedback felt that it would be most appropriate place and, further, that this work bears some relation to XBL. Not sure why this had some relation with XBL. Unless you are planning to put the template based DOM nodes to anonymous DOM. What do you think? - Is this something you'd like to be implemented in the browsers, and if yes, why? What would be the reasons to not just use script libraries (like your prototype). If the have-to-change-HTML-parser like parts could be removed, this all feels like something for JS + Proxy objects, just like what you've done in the prototype. - Is there a reason why you have chosen to create yet another datastorage like object (although your Model is just a kind of proxy)? Couldn't you reuse for example IndexedDB? XUL Templates can be bound to sqlite, XML and RDF. - Model looks in many ways like JS-fied and simplified XForms model/instance. Have you investigated if there are important use cases which XForms can handle (because it has more powerful binding mechanism) but MDV can't? Are there plans to extend the "Path language", or ideas how it could be extended? (XForms has extensions to XPath) In general I'm not too happy to see yet another selector/path language. Would be great if some existing one could be reused. Sure, some parts of the proposed language look quite a bit like JSON, but there are other parts which are something very different. - It is not quite clear to me how the Model-as-a-proxy works. What if the raw object has getters or setters, how does the Model work in that case? (Calling a getter or setter may do any kinds of changes to the raw object, and/or to the model) - How does Model.get handle objects which have circular references? How does the Path language work in that case? - How does the observing mechanism handle the case when there are several observers for the same property and the first one which gets notified updates the relevant property (and then sets some flag to itself to not handle following updates to prevents notification loops). What values are notified to other callbacks? - Nit, why are you using document.querySelector('#example') in the examples. The good old document.getElementById("example") should be faster ;) - "Child nodes are not considered to be a part of the DOM. During parsing, they are lifted out..." Huh, you really want to alter HTML parsing? - "If a template element is created via script, any children are removed and attached to the instancePrototype when the template element is attached to a document." What if the template is already in DOM when the new child elements are added. It sounds *very* strange to add new special cases to DOM Core methods. - What kind of property is instancePrototype? NodeList? - What does this mean "Any instances of a template must exist as a sequence of nextSiblings following the template element itself, with each instance being terminated by a HTMLTemplateInstanceElement." I couldn't see any elements in the examples. - At which point and how are the instances created? How are mutation events handled? (Unfortunately we do need to care about mutation events still some time before there is a replacement.) -Olli
Re: Model-driven Views
Thank, Nathan. I hadn't known of Knockout, but it looks pretty great. Conceptually, its design is very similar to MDV. Notably, the two big items: -Observable JS object properties and Arrays. -DOM-based template production (although they work with JQuery templates which are string-based). The automatic dependency tracking is interesting. We looked at some work published by Adobe/Texas A&M on declarative property models (http://parasol.cs.tamu.edu/~jarvi/papers/gpce08.pdf, a very unsophisticated example in our use_cases http://mdv.googlecode.com/svn/trunk/use_cases/property_model.html). Knockout re-affirms for me that: -Dynamic web apps increasingly load one or more views as HTML but talk to their servers via a data API. Having to write lots of imperative code which shuttles data into & out-of the DOM is a bummer. It's not especially interesting code and it tends to be error prone. A declarative approach can do much better. -There are basically only two approaches to templating: DOM-based (MDV, Knockout, Angular, JSTemplate) & String-based (JQuery, and a ton of others). In the video, Steve explains (at about 12:40), indirectly, that DOM-based is required if you are going to dynamically update your view: performance. The other reason is DOM-stability. -In order to get this kind of approach to work, you need some way of observing when data has changed. There are four options for this that I know of: 1) Run-time support for direct observation (e.g. Adobe Flex, WPF) 2) Value-holder pattern (e.g. Knockout, Sproutcore) 3) Proxy pattern (e.g. MDV) 4) Dirty checking (e.g. Angular) The only two options available to webdevs are 2 & 4, and both currently require some fairly unnatural contortions. On Mon, Apr 25, 2011 at 12:26 PM, Nathan Kitchen wrote: > Have you heard of knockout.js? It's an MVVM pattern based on JQuery, if > you're not aware of it you may be interested to see their approach. > Official site: > http://knockoutjs.com/ > Recent MIX event: > http://channel9.msdn.com/Events/MIX/MIX11/FRM08 > Just FYI as it was related... > > On 23 April 2011 01:35, 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. It's not >> complete and there are things we're not happy with, but it's >> self-consistent enough that you can start to imagine what a full >> design might look like. >> >> We hope to get others interested in collecting requirements/use cases >> and fleshing out a good solution. >> >> We're starting the discussion here because a few people in this group >> from whom we got early feedback felt that it would be most appropriate >> place and, further, that this work bears some relation to XBL. >> >> What do you think? >> >> > >
Re: Model-driven Views
The model-based UI effort is focused on UI design and making it easier to maintain, as well as adaptation to different contexts, and support for accessibility. As such authors wouldn't work with HTML5 directly, as this would be generated automatically from the models, guided by the author's preferences and UI skins. The approach can be used with JavaScript libraries for the desired run-time behavior, e.g. a custom UI control set, and the approach would complement work on run-time extensions for MVC. Note that a particularly long standing effort on applying the MVC design pattern to the Web is XForms where the model is represented as a DOM tree. On Tue, 2011-04-26 at 07:24 -0400, Arthur Barstow wrote: > Hi Rafael, > > On Apr/22/2011 8:35 PM, ext 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. It's not > > complete and there are things we're not happy with, but it's > > self-consistent enough that you can start to imagine what a full > > design might look like. > > > > We hope to get others interested in collecting requirements/use cases > > and fleshing out a good solution. > > > > We're starting the discussion here because a few people in this group > > from whom we got early feedback felt that it would be most appropriate > > place and, further, that this work bears some relation to XBL. > > > > What do you think? > > FYI, the W3C has done some related work although I'm not sure how > closely related it is to MDV: > >Model-Based UI XG Final Report >http://www.w3.org/2005/Incubator/model-based-ui/XGR-mbui-20100504/ > > There is also a proposed WG to continue work done by the above XG: > >(DRAFT) Model-Based UI Working Group Charter >http://www.w3.org/2011/01/mbui-wg-charter > > -AB > > > > -- Dave Raggett http://www.w3.org/People/Raggett
Re: Model-driven Views
Hi Rafael, On Apr/22/2011 8:35 PM, ext 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. It's not complete and there are things we're not happy with, but it's self-consistent enough that you can start to imagine what a full design might look like. We hope to get others interested in collecting requirements/use cases and fleshing out a good solution. We're starting the discussion here because a few people in this group from whom we got early feedback felt that it would be most appropriate place and, further, that this work bears some relation to XBL. What do you think? FYI, the W3C has done some related work although I'm not sure how closely related it is to MDV: Model-Based UI XG Final Report http://www.w3.org/2005/Incubator/model-based-ui/XGR-mbui-20100504/ There is also a proposed WG to continue work done by the above XG: (DRAFT) Model-Based UI Working Group Charter http://www.w3.org/2011/01/mbui-wg-charter -AB
Re: Model-driven Views
On Mon, Apr 25, 2011 at 9:14 PM, Boris Zbarsky 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. ~TJ
Re: Model-driven Views
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? -Boris
Re: Model-driven Views
Have you heard of knockout.js? It's an MVVM pattern based on JQuery, if you're not aware of it you may be interested to see their approach. Official site: http://knockoutjs.com/ Recent MIX event: http://channel9.msdn.com/Events/MIX/MIX11/FRM08 Just FYI as it was related... On 23 April 2011 01:35, 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. It's not > complete and there are things we're not happy with, but it's > self-consistent enough that you can start to imagine what a full > design might look like. > > We hope to get others interested in collecting requirements/use cases > and fleshing out a good solution. > > We're starting the discussion here because a few people in this group > from whom we got early feedback felt that it would be most appropriate > place and, further, that this work bears some relation to XBL. > > What do you think? > > >