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
