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
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: Moving XBL et al. forward
On 03/10/2011 02:56 PM, Tab Atkins Jr. wrote: serialization, but it's easy to imagine it also having an XML serialization for use directly in SVG or similar. ~TJ Certainly, we'd prefer to have an XML representation of the component language for use with XForms for similar reasons. XForms is not a host language, but works together with other XML applications such as XHTML and SVG. We've explored an HTML representation for use with HTML serializations, but not made any efforts in that direction due to lack of interest from users. But it would certainly be possible; the data binding to XML (or JSON, in XForms 1.2) data is unrelated to the syntax used to express the bindings. Leigh.
Re: Moving XBL et al. forward
Here's my best understanding of the ansers to these questions from the Forms WG perspective: We continue to cheer for the development of a component system for the HTML5 stack, as it will make things easier for end-user authors and for framework developers, whether they choose to express their ideas in markup, JavaScript, or a mix. We do not feel it is necessary for the desktop and mobile browser implementations of a new component language to handle namespaced XML. However, as XForms is, and will continue to be, a markup-based layer to other W3C technologies, many of which will, going forward, be specified as JavaScript interfaces (XHR, DOM, etc.), we want to ensure that an extension or optional feature can be used to accept namespaced XML markup and produce output including namespaced XML markup. We expect to see XForms implemented in popular mobile and desktop browsers (as it currently is) in JavaScript, XSLT, and in server-side systems. Thus, a syntax that can cleanly be extended to bind to (and to produce) namespaced markup is important to us. Our hope is that the extensions necessary to express this will be minimal. While our preference would be to have this syntax described in the main component language recommendation, we can live it with being expressed in another recommendation which merely adds on the syntax. As for re-casting XBL as a series of CSS extensions, itself not expressed in markup, we have not discussed that issue yet, but if the proposal moves further forward we will. Leigh. On 03/09/2011 06:14 AM, Arthur Barstow wrote: Ian, Leigh, Dimitri, All, On March 11, the agenda of the so-called Hypertext Coordination Group [HCG] will include XBL [XBL] to continue related discussions they had during their Feb 11 call [Feb-11-Mins]. I wasn't present at that call but based on those meeting minutes and what Leigh said last month [Leigh], I think the gist of the March 11 discussion will revolve around: * What is the latest implementation status of the XBL2 CR [XBL2-CR] and Hixie's September 2010 version [XBL-ED] (previously referred to as XBL2-cutdown)? * Which members of WebApps want to continue with the XML-based version of XBL2 as codified in the XBL2 CR? If you are groupin this , what firm commitments can you make to push the spec along the REC track? Would you object to the Forms WG taking over this spec? * Which members of WebApps want to continue with the non-XML version as Hixie created last September? If you are in this group, what firm commitments can you make to push this version along the REC track (especially implementation)? * Should the WG pursue Dimitri Glazkov's Component Model proposal [Component]? If yes, who is willing to commit to work on that spec? Please send comments on the above as soon as possible (preferably before 10:00am Boston time on March 11). -Art Barstow [XBL] http://www.w3.org/2008/webapps/wiki/XBL [HCG] http://www.w3.org/MarkUp/CoordGroup/ [Feb-11-Mins] http://lists.w3.org/Archives/Public/public-hypertext-cg/2011JanMar/0007.html [Leigh] http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0243.html [XBL2-CR] http://www.w3.org/TR/2007/CR-xbl-20070316/ [XBL2-ED] http://dev.w3.org/2006/xbl2/ [Component] http://wiki.whatwg.org/wiki/Component_Model_Use_Cases
Re: What is happening with XBL?
We've discussed this on Forms WG and are preparing a reply, but in the interest of time I'll give a summary: The Forms WG members are pleased with the progress toward real-world XBL and shadow-DOM injection facilities in popular desktop browsers, and want to encourage that work. Additionally, a number of our members are using a cut-down version of XBL2 as a macro language for composing XForms and HTML components, usually in a transformation step that takes place before markup is delivered to popular desktop browsers. The use cases which public-webapps is currently studying for XBL also include component definitions, so we feel that is harmony between the goals, and *hope that we can work together to a common specification*, though perhaps with optional features. While there are non-browser implementations of XForms, most XForms implementations for popular desktop browsers are using JavaScipt and other in-browser facilities to provide a markup-based, declarative interface to the native facilities available in the browser, and we see progress in the shadow-DOM front as a great benefit. Our hope is that as HTML5 moves forward that it gets easier, rather than harder, to provide XForms declarative markup-based access to browser facilities, and we hope to leverage the eventual XBL-like shadow-DOM injection facility as part of this delivery, /as well as/ retain the ability to define and use components containing a mix of HTML and XForms markup. A number of XForms implementations make use of XBL or cut-down versions of XBL2 to develop widgets and composite controls: 1A: In Mozilla XForms the XForms markup is bound with full-blown XBL with shadow DOM, CSS bindings, JavaScript etc. 1B: In all others, a cut-down XBL2 is used as a simple macro-language for composing compound form controls out of HTML and XForms markup, without any participation in the underlying HTML4 browser shadow DOM. In these cases, XSLT is also used to provide a transformation step, providing the ability to use attribute-value templates to perform substitutions instead of simply copying of attribute values. * Being able to unify these two uses of XBL is our goal, and obviously if a better version of XBL is widely deployed in popular desktop browsers, that task becomes easier. * However, there is one area of concern, and that is that it the ability to bind to markup in the XForms namespace, or to produce output markup in the XForms namespace may be removed from XBL. Ian Hixson's proposal to eliminate namespaces and event support from XBL2 is the most troubling issue for us. To expand on this point, for case 1A, we feel that it's necessary to provide an ability to match markup with namespaced elements, and also to produced namespaced-elements (mostly XForms in both cases) as output. A clear idea of when XSLT PIs are processed and when XBL definitions are processed might go far toward helping resolve this issue.However, for case 1B, where the XBL implementation is not within the browser, optional namespace support in the Recommendation may be sufficient. It may be that if XSLT PI support is retained, in-browser implementations will be able to continue to use that to provide the namespace matching necessary to disambiguate XForms from underlying HTML4 or HTML5 elements, and then the shadow-DOM facility can operate at a separate level. Some implementations have had success in using in-browser XSLT or in-browser JavaScript re-parsing of the live DOM to bridge between the XForms markup and HTML+JavaScript implementation. However, a clear ability to do one of these two things from within XBL (interpose XSLT transformations, with namespace binding, or to use JavaScript to read the incoming DOM with un-munged namespaced elements) would be necessary to sure a path to success with an XForms+XHTML+XBL - HTML5+XBL in-browser conversion (i.e., to allow XBL to operate both to expand into XForms markup and to participate in the in-browser behavior). Additionally, some of our WG members feel that XPath selectors would be more useful for case 1B. However, I believe we are approaching a consensus that CSS selectors are OK for case 1A, so my personal belief is that we will most likely not be asking for XPath selectors. Leigh. On 01/24/2011 05:24 AM, Arthur Barstow wrote: [ Bcc: set to: public-fo...@w3.org ; please set Reply-To: to just public-webapps@w3.org ] XBL Fans, In case you missed it, about a week ago, Anne van Kesteren wrote a nice blog about some of the recent activities with XBL including pointers to some related work by Dimitri Glazkov (e.g. Use Cases). Given AvK's blog is short-ish, I'll quote it here: [[ http://annevankesteren.nl/2011/01/xbl What is happening with XBL? 15th January 2011 What is happening with XBL? Despite quite a bit of interest when XBL 2.0 http://www.w3.org/TR/2007/CR-xbl-20070316/ was developed it has not made it into browsers
