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: [IndexedDB] Closing on bug 9903 (collations)
On Fri, Apr 29, 2011 at 3:32 PM, Jonas Sicking jo...@sicking.cc wrote: I agree that we will eventually want to standardize the set of allowed collations. Similarly to how we'll want to standardize on one set of charset encodings supported. However I don't think we, in this spec community, have enough experience to come up with a good such set. So it's something that I think we should postpone for now. As I understand it there is work going on in this area in other groups, so hopefully we can lean on that work eventually. (Disclaimer: I never really tried to figure out how IndexedDB works, and I haven't seen the past discussion on this topic. However, I know a decent amount about database collations in practice from my work with MediaWiki, which included adding collation support to category pages last summer on a contract with Wikimedia. Maybe everything I'm saying has already been brought up before and/or everyone knows it and/or it's wrong, in which case I apologize in advance.) The Unicode Collation Algorithm is the standard here: http://www.unicode.org/reports/tr10/ It's pretty stable (I think), and out of the box it provides *vastly* better sorting than binary sort. Binary sort doesn't even work for English unless you normalize case and avoid punctuation marks, and it's basically useless for most non-English languages. Some type of UCA support in browsers would be the way to go here. UCA doesn't work perfectly for all locales, though, because different locales sort the same strings differently (French handling of accents, etc.). The standard database of locale-specific collations is CLDR: http://cldr.unicode.org/ CLDR tends to have several new releases per year. For instance, 1.9.1 was released this March, three versions were released last year, and five were released in 2009. Just looking at the release notes, it seems that most if not all of these releases update collation details. Because of how collations are actually used in databases, any change to the collation version will require rebuilding any index that uses that collation. I don't think it's a good idea for browsers to try packaging such rapidly-changing locale data. If everyone had Chrome's release and support schedule, it might work okay -- if you figured out a way to handle updates gracefully -- but in practice, authors deal with a wide range of browser ages. It's not good if every user has a different implementation of each collation. Nor if browsers just use a frozen and obsolescent collation version. I also don't know how realistic implementers would find it to ship collation support for every language CLDR supports -- the CLDR download is a few megabytes zipped, but I don't know how much of that browsers would need to ship to support all its tailorings. The general solution here would be to allow the creation of indexes based on a user-supplied function. I.e., the user-supplied function would (in SQL terms) take the row's data as input, and output some binary string. That string would be used as the key in the index, instead of any of the column values for the row. PostgreSQL allows this, or so I've heard. Then you could implement UCA (optionally with CLDR tailorings) or any other collation algorithm you liked in JavaScript. Of course, we can't expect authors to reimplement the UCA if they want to get decent sorting. It would make sense for browsers to expose some default sort functions, but I'm not familiar enough with UCA or CLDR to say which ones would be best in practice. It might make sense to expose some medium-level primitives that would allow authors to easily overlay tailoring on the basic UCA algorithm, or something. Or maybe it would really make sense to expose all of CLDR's tailored collations. I'm not familiar enough with the specs to say. But for the sake of flexibility, allowing indexes based on user-defined functions is the way to go. (They're useful for things other than collations, too.) The proposed ECMAScript LocaleInfo.Collator looks like it doesn't currently support this use-case, since it provides only sort functions and not sortkey generation functions: http://wiki.ecmascript.org/doku.php?id=strawman:i18n_api If browsers do provide sortkey generation functions based on UCA, some versioning mechanism will need to be used, particularly if it supports tailored sortkeys. FWIW, MySQL provides some built-in collation support, but MediaWiki doesn't use it, because it supports too few languages and is too inflexible. MediaWiki's stock localization has 99% support for the 500 most-used messages in 175 different languages, and the couple dozen locales that MySQL supports aren't acceptable for us. Instead, we store everything with a binary collation, and are moving to a system where we compute the UCA sortkeys ourselves and put them in their own column, which we use for sorting. MediaWiki's i18n people can be reached in #mediawiki-i18n on freenode or the Mediawiki-i18n list
paste events and HTML support - interest in exposing a DOM tree?
Hi,
a question related to the evolving draft on
http://www.w3.org/TR/clipboard-apis/ (which actually is slightly better
styled on http://dev.w3.org/2006/webapi/clipops/clipops.html - I should
figure out why ;-))
We want to enable some sort of access to HTML code if the user pastes
formatted text from an application that places HTML on the clipboard.
However, the browser will have to implement some security restrictions
(see relevant section of the spec - though it's just a draft), and in some
cases process the HTML to deal with embedded data when there are sub-parts
on the clipboard.
To handle both security algorithms and any embedded data, the browser will
probably need to parse the HTML. So actually, when you call
event.clipboardData.getData('text/html') the browser will get HTML from
the clipboard, parse it, do any work required by security and data embeds
rules on the DOM, and then serialize the code (possibly after modifying
the DOM) to pass it on to the script. Of course the script will want to do
its own processing, which will probably at some point require parsing the
code again..
So, to make things more efficient - would it be interesting to expose the
DOM tree from the browser's internal parsing? For example, we could define
event.clipboardData.getDocumentFragment()
which would return a parsed and when applicable sanitized view of any
markup the implementation supports from the clipboard. Rich text editors
could now use normal DOM methods to dig through the contents and
remove/add cruft as they wish on the returned document fragment, before
doing an appendChild() and preventing the event's default action.
Thoughts?
--
Hallvord R. M. Steen, Core Tester, Opera Software
http://www.opera.com http://my.opera.com/hallvors/
