Re: Model-driven Views
From: Rafael Weinsteinrafa...@google.com mailto:rafa...@google.com?Subject=Re%3A%20Model-driven%20ViewsIn-Reply-To=%253CBANLkTimZcXiO8U8xHg2Y6eT4igixkCiF7w%40mail.gmail.com%253EReferences=%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,
html
head
model
instance
quote
colorred/color
size3/size
quote
/instance
submission id=price resource=/rfq method=post replace=instance /
/model
/head
body
input ref=color
labelColor: /color
/input
input ref=size
labelSize: /label
/input
output ref=price
labelYour price: /label
/output
submit submission=buy
labelBuy/label
/submit
/body
/html
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:
html
head
model
instance id=rfq
quote
colorred/color
size3/size
quote
/instance
instance id=quoteempty //instance
submission id=price resource=/rfq method=post
ref=instance('rfq') replace=instance target=quote /
/model
/head
body
/body
input ref=color
labelColor: /color
/input
input ref=size
labelSize: /label
/input
output ref=instance('quote')/price
labelYour price: /label
/output
submit submission=buy
labelBuy/label
/submit
/body
/html
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:
html
head
model
instance id=rfq
quote
colorred/color
size3/size
quote
/instance
instance id=quoteempty //instance
submission id=price resource=/rfq method=get ref=instance('rfq')
replace=instance target=quote /
/model
/head
body
/body
input ref=color
labelColor: /color
/input
input ref=size
labelSize: /label
/input
output ref=instance('quote')/price
labelYour price: /label
/output
submit submission=buy
labelBuy/label
/submit
/body
/html
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:
html
head
model
instance id=rfq src=initial-quote.xml /
instance
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 m...@apple.com 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
On 5/6/11, Rafael Weinstein rafa...@google.com 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
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
Does WebApps want to do work in Model-driven Views area?
Hi All, Pardon the interruption here to digress a bit to look at Rafael's proposal from the process perspective ... [Charter] defines WebApps' scope and explicit deliverables. Depending on how the proposal is viewed, (perhaps) at least part of it could be rationalized by being related to XBL templates. Nevertheless, I would appreciate feedback on - should WebApps start new work in this area? * If yes - why should WebApps take on this new deliverable? * If no - would some other group be a better place to do work in this area? Options here would include: a new Incubator Group [XG] that would have its own mail list to build consensus on the UCs, requirements and to start preliminary spec work; a new WG; some existing WG (Chaals mentioned some related work done in XForms); added to the new WG Dave Raggett mentioned; other options? -Art Barstow [Charter] http://www.w3.org/2010/webapps/charter/ [XG] http://www.w3.org/2005/Incubator/about.html Original Message Subject:Re: Model-driven Views Resent-Date:Tue, 3 May 2011 01:08:53 + Resent-From:public-webapps@w3.org Date: Mon, 2 May 2011 18:05:17 -0700 From: ext Rafael Weinstein rafa...@google.com To: Maciej Stachowiak m...@apple.com CC: o...@pettay.fi, public-webapps@w3.org 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
Re: Does WebApps want to do work in Model-driven Views area?
On 05/03/2011 02:38 PM, Arthur Barstow wrote: Hi All, Pardon the interruption here to digress a bit to look at Rafael's proposal from the process perspective ... [Charter] defines WebApps' scope and explicit deliverables. Depending on how the proposal is viewed, (perhaps) at least part of it could be rationalized by being related to XBL templates. Well, to me XBL templates are still quite different to MDV templates. XBL needs to handle all sort of attribute value and text value copying/forwarding and building the actual instance data in anonymous DOM and special event handling in the anonymous DOM etc. Nevertheless, I would appreciate feedback on - should WebApps start new work in this area? * If yes - why should WebApps take on this new deliverable? * If no - would some other group be a better place to do work in this area? Options here would include: a new Incubator Group [XG] that would have its own mail list to build consensus on the UCs, requirements and to start preliminary spec work; a new WG; some existing WG (Chaals mentioned some related work done in XForms); added to the new WG Dave Raggett mentioned; other options? I think I'm still missing some information before I could say yes or no. Basically I don't know what kinds of requirements led to the current design of MDV and why exactly it can't be implemented as a js library if some rather small primitives were added to the web platform. (Those small primitives should be defined either in webapps or whatwg, I think.) -Olli -Art Barstow [Charter] http://www.w3.org/2010/webapps/charter/ [XG] http://www.w3.org/2005/Incubator/about.html Original Message Subject: Re: Model-driven Views Resent-Date: Tue, 3 May 2011 01:08:53 + Resent-From: public-webapps@w3.org Date: Mon, 2 May 2011 18:05:17 -0700 From: ext Rafael Weinstein rafa...@google.com To: Maciej Stachowiak m...@apple.com CC: o...@pettay.fi, public-webapps@w3.org 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
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 already
Re: Model-driven Views
On 5/2/11, Rafael Weinstein rafa...@google.com 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
On Sat, 23 Apr 2011 02:35:53 +0200, Rafael Weinstein rafa...@google.com 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: div class=entry div id=repeatformcontainer div id=tem1 repeat=template repeat-min=2 repeat-max=5 input type=text name=product.[tem1] value=one thing button type=removeRemove/button button type=move-upMove Up/button button type=move-downMove Down/buttonbr / /div pbutton type=add template=tem1Add/button /div /div 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 04/29/2011 04:11 AM, Garrett Smith wrote: On 4/28/11, Olli Pettayolli.pet...@helsinki.fi 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 Apr 28, 2011, at 5:46 AM, Alex Russell wrote: On Thu, Apr 28, 2011 at 12:09 PM, Maciej Stachowiak m...@apple.com 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 template 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 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
On Thu, Apr 28, 2011 at 2:02 AM, Maciej Stachowiak m...@apple.com 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 28, 2011, at 2:33 AM, Jonas Sicking wrote: On Thu, Apr 28, 2011 at 2:02 AM, Maciej Stachowiak m...@apple.com 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 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 Tue, Apr 26, 2011 at 7:32 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Mon, Apr 25, 2011 at 9:14 PM, Boris Zbarsky bzbar...@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. Regards
Re: Model-driven Views
On Thu, Apr 28, 2011 at 12:09 PM, Maciej Stachowiak m...@apple.com wrote: On Apr 28, 2011, at 2:33 AM, Jonas Sicking wrote: On Thu, Apr 28, 2011 at 2:02 AM, Maciej Stachowiak m...@apple.com 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 template 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 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 4/28/11, Olli Pettay olli.pet...@helsinki.fi 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
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 templateinstance 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
On Wed, Apr 27, 2011 at 08:33, Olli Pettay olli.pet...@helsinki.fi 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 template 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
audio autoplay, 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:
template iterate
img src={{data.src}}.png
/template
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:
div id=a
template instantiate
p id=b{{ data }}/p
/template
/div
...
script
document.getElementById('a').model = {data: 'Hello World'};
assertEquals('Hello World', document.getElementById('b').textContent);
/script
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 template more like
script and treat the content as CDATA. This would require some more
work over script because we need to allow nested template but that
seems acceptable. The downside to this solution is that we want people
to be able to build template elements on the fly using plain old DOM
core.
- What kind of property is instancePrototype? NodeList?
It is not exposed. Internally we used a list of Nodes.
- 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 templateinstance elements in the examples.
The idea is that instances become siblings to the template element.
The HTMLTemplateInstanceElement is an artifact of an older design.
Between every set of instance nodes we want there to be a delimiter.
template iterate=lista/b//template
a/b/
!-- delimiter --
a/b/
!-- delimiter --
...
The main motivation for having a delimiter is to allow script to add
and remove nodes to instances. With delimiters we can tell what nodes
belong to each instance, even if they were not added by the template
iterator. This allows the template iterator to know what to move and
remove when items in the collection are moved and removed.
Our initial design had an element (with display:none) but making that
into a comment has some benefits. For example it does not break CSS
sibling selectors, DOM nextElementSibling, children, etc all work as
expected.
Sorry I didn't address all your comments/questions but this is already
getting long. We'll follow up with another email trying to answer the
other questions.
--
erik
Re: Model-driven Views
On 04/27/2011 09:13 PM, Erik Arvidsson wrote: On Wed, Apr 27, 2011 at 08:33, Olli Pettayolli.pet...@helsinki.fi 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 wanttemplate 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 audio autoplay, 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. audio works even if it is not in document, and so does img. 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 11:47 AM, Olli Pettay olli.pet...@helsinki.fi wrote: On 04/27/2011 09:13 PM, Erik Arvidsson wrote: 1. We wanttemplate 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 audio autoplay, 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. audio works even if it is not in document, and so does img. But I see the problem you're trying to avoid. Yeah, we basically just want the actual nodes inside of template 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
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 olli.pet...@helsinki.fi 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 were after. - It is not quite clear to me how the
Re: Model-driven Views
On Mon, Apr 25, 2011 at 9:14 PM, Boris Zbarsky bzbar...@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. ~TJ
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
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 d...@w3.org http://www.w3.org/People/Raggett
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 AM 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 w...@nathankitchen.com 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 rafa...@google.com 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?
Model-driven Views
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
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 rafa...@google.com 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
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
