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

Received on Wednesday, 27 April 2011 15:34:08 UTC