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: [widgets] missing tests?
On Wed, Dec 1, 2010 at 11:41 AM, Scott Wilson scott.bradley.wil...@gmail.com wrote: Tests bd,be,bf for assertion ta-DwhJBIJRQN seem to have gone - have these been removed from the test suite or been renamed? I think those tests were redundant (or wrong), so I removed them. As it was a while ago, I can't remember the exact details. -- Marcos Caceres http://datadriven.com.au
Re: [widgets] Widget Updates tests?
On Mon, Mar 28, 2011 at 3:59 PM, Scott Wilson scott.bradley.wil...@gmail.com wrote: Hi everyone, Are there any tests available - even informal ones - for the Widget Updates[1] spec? None yet :( -- Marcos Caceres http://datadriven.com.au
Re: Widget URI tests
On Wed, Mar 9, 2011 at 11:11 AM, Bryan Sullivan bls...@gmail.com wrote: Hi all, I’m working to develop some widget URI tests. I notice there is nothing yet linked from the pubstatus page. I’ve attached a widget which performs one simple test: verify if the window’s location.protocol attribute is “widget:”. This was modeled upon the widget interface tests. It passes under Opera 11.01. Looking into the other normative requirements, I’d like the group’s input on what other requirements in the Widgets URI spec would be considered high-priority for an “Acid test” level of support validation. I think making widget:// respond with http codes when resources are not found would be a big help. This would allow widget:// to be used with jQuery mobile and XMLHTTPRequest in general. -- Marcos Caceres http://datadriven.com.au
Re: [widgets] Dig Sig spec
Hi Marcos, On Apr/25/2011 11:53 AM, ext Marcos Caceres wrote: I've been reviewing and trying to implement the widgets dig sig spec and I'm finding that there is a lot of redundancies and inconsistencies with the way it is written. Although the conformance requirements are fairly clear, the main problem is that the spec is a bit confused when it comes to algorithms and processing. It also states things that really should just be deferred to XML Dig Sig 1.1. If it's ok with everyone, I want to have a go at rewriting it with the goal of making it simpler to implement. Unless there are some relatively major bugs in the spec that are affecting interoperability, then I wouldn't recommend doing that. There are real costs for this proposal: for implementors and developers to review new WDs, external groups to consider (e.g. XML Security WG, WAC) as well as the WG's overhead of processing new publication requests. If folks have resources to spare on the Widgets specs, it seems like the higher priority would be to complete work already started. -Art Barstow
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: [widgets] Dig Sig spec
On Tuesday, April 26, 2011 at 1:13 PM, Arthur Barstow wrote: Hi Marcos, On Apr/25/2011 11:53 AM, ext Marcos Caceres wrote: I've been reviewing and trying to implement the widgets dig sig spec and I'm finding that there is a lot of redundancies and inconsistencies with the way it is written. Although the conformance requirements are fairly clear, the main problem is that the spec is a bit confused when it comes to algorithms and processing. It also states things that really should just be deferred to XML Dig Sig 1.1. If it's ok with everyone, I want to have a go at rewriting it with the goal of making it simpler to implement. Unless there are some relatively major bugs in the spec that are affecting interoperability, then I wouldn't recommend doing that. There are real costs for this proposal: for implementors and developers to review new WDs, external groups to consider (e.g. XML Security WG, WAC) as well as the WG's overhead of processing new publication requests. I understand the costs to implementers, but I'm not proposing to radically change the conformance requirements of the specification (which will remain the same except were things are clearly broken). The major bugs in the spec are to do with the unnecessary restrictions that the spec imposes wrt canonicalization and other algorithms and signature formats. WAC already willfully violated the canonicalization requirement in WAC 1, which shows the spec is broken. I propose to fix this by increasing the reliance on XMLDigSig 1.1 for validation and generation and making the spec only recommend certain formats, algorithms, and key lengths. This will make the specification a proper profile of XML DigSig 1.1, which currently it is not. It will also allow WAC 1.0 runtimes to conform to the spec without impacting future WAC versions. If folks have resources to spare on the Widgets specs, it seems like the higher priority would be to complete work already started. My opinion is that this spec is too important to leave it in its current state.
Re: [widgets] Dig Sig spec
On Apr/26/2011 7:40 AM, ext Marcos Caceres wrote: On Tuesday, April 26, 2011 at 1:13 PM, Arthur Barstow wrote: Hi Marcos, On Apr/25/2011 11:53 AM, ext Marcos Caceres wrote: I've been reviewing and trying to implement the widgets dig sig spec and I'm finding that there is a lot of redundancies and inconsistencies with the way it is written. Although the conformance requirements are fairly clear, the main problem is that the spec is a bit confused when it comes to algorithms and processing. It also states things that really should just be deferred to XML Dig Sig 1.1. If it's ok with everyone, I want to have a go at rewriting it with the goal of making it simpler to implement. Unless there are some relatively major bugs in the spec that are affecting interoperability, then I wouldn't recommend doing that. There are real costs for this proposal: for implementors and developers to review new WDs, external groups to consider (e.g. XML Security WG, WAC) as well as the WG's overhead of processing new publication requests. I understand the costs to implementers, but I'm not proposing to radically change the conformance requirements of the specification (which will remain the same except were things are clearly broken). The major bugs in the spec are to do with the unnecessary restrictions that the spec imposes wrt canonicalization and other algorithms and signature formats. WAC already willfully violated the canonicalization requirement in WAC 1, which shows the spec is broken. I propose to fix this by increasing the reliance on XMLDigSig 1.1 for validation and generation and making the spec only recommend certain formats, algorithms, and key lengths. This will make the specification a proper profile of XML DigSig 1.1, which currently it is not. It will also allow WAC 1.0 runtimes to conform to the spec without impacting future WAC versions. If folks have resources to spare on the Widgets specs, it seems like the higher priority would be to complete work already started. My opinion is that this spec is too important to leave it in its current state. Well, you started with a relatively ambiguous characterization of a need to eliminate redundancies and inconsistencies and now I see you think the spec as written has resulted in willful violations of the spec and of course those are quite different. Since this spec is in the Candidate state (and as such, perhaps already deployed), I think it would be helpful if you would please flesh out all the changes and bug(s) you propose must be fixed ^1. Then we should be able to have a more informed discussion re if it's OK to have a go at rewriting. -AB ^1 presumably you should use Tracker since it is already being used for the widget specs
Re: [widgets] Dig Sig spec
On Tuesday, April 26, 2011 at 2:02 PM, Arthur Barstow wrote: Well, you started with a relatively ambiguous characterization of a need to eliminate redundancies and inconsistencies and now I see you think the spec as written has resulted in willful violations of the spec and of course those are quite different. Correct. But one really led to the other. The reality is that very few people who implemented the spec really read the spec in detail. Most people seemed to have been working from the examples. This is normal and to be expected. Cleaning it up a bit should make it easier to follow. Since this spec is in the Candidate state (and as such, perhaps already deployed), I think it would be helpful if you would please flesh out all the changes and bug(s) you propose must be fixed ^1. Then we should be able to have a more informed discussion re if it's OK to have a go at rewriting. I'm ok with that, but would prefer to do it like this: 1. make a mirror copy of the spec. 2. make all the edits I think need to be made. It's not many, as the spec is relatively small (~14 pages). 3. make a diff of the two documents to build the list of changes. 4. propose the complete list of changes to the group. 5. let the group decide which changes they accept or reject or need further discussion. If the new spec is take wholesale, then great. Otherwise, it's easy to backtrack on proposed changes. This is how I've done this kinds of changes in the past and it's always worked out ok.
[widgets] Proposal to update Dig Sig spec; deadline May 3
Widget People - if you have any objections/concerns re Marcos' proposal below, please respond by May 3 at the latest. (For some additional context, the start of the thread is [1]). Marcos - if no major objections/concerns are raised by this deadline, please proceed as you propose below. -Thanks, AB [1] http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/0306.html Original Message Subject:Re: [widgets] Dig Sig spec Date: Tue, 26 Apr 2011 14:19:44 +0200 From: ext Marcos Caceres marcosscace...@gmail.com To: Arthur Barstow art.bars...@nokia.com CC: public-webapps public-webapps@w3.org On Tuesday, April 26, 2011 at 2:02 PM, Arthur Barstow wrote: Well, you started with a relatively ambiguous characterization of a need to eliminate redundancies and inconsistencies and now I see you think the spec as written has resulted in willful violations of the spec and of course those are quite different. Correct. But one really led to the other. The reality is that very few people who implemented the spec really read the spec in detail. Most people seemed to have been working from the examples. This is normal and to be expected. Cleaning it up a bit should make it easier to follow. Since this spec is in the Candidate state (and as such, perhaps already deployed), I think it would be helpful if you would please flesh out all the changes and bug(s) you propose must be fixed ^1. Then we should be able to have a more informed discussion re if it's OK to have a go at rewriting. I'm ok with that, but would prefer to do it like this: 1. make a mirror copy of the spec. 2. make all the edits I think need to be made. It's not many, as the spec is relatively small (~14 pages). 3. make a diff of the two documents to build the list of changes. 4. propose the complete list of changes to the group. 5. let the group decide which changes they accept or reject or need further discussion. If the new spec is take wholesale, then great. Otherwise, it's easy to backtrack on proposed changes. This is how I've done this kinds of changes in the past and it's always worked out ok.
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: [IndexedDB] which names can be the empty string?
I have no opinion whatsoever, except that the spec should specify it one way or the other so I can close these bugs. :) On Mon, Apr 25, 2011 at 9:35 PM, Jonas Sicking jo...@sicking.cc wrote: Good question. I don't have a strong opinion. It makes sense to me to allow anything. Don't know I there was any reason we added explicit checks. / Jonas On Monday, April 25, 2011, Mark Pilgrim pilg...@google.com wrote: 1. Can an object store be named the empty string? 2. Can an index be named the empty string? Other things, like databases, are allowed to have a name that is the empty string. Mozilla has tests that expect both of the above cases to fail, but as I'm porting those tests to WebKit, it's not clear from my reading of the spec whether those tests are valid. -Mark Pilgrim
Re: [widgets] Proposal to update Dig Sig spec; deadline May 3
On Tue, Apr 26, 2011 at 8:50 AM, Arthur Barstow art.bars...@nokia.com wrote: Widget People - if you have any objections/concerns re Marcos' proposal below, please respond by May 3 at the latest. (For some additional context, the start of the thread is [1]). Marcos - if no major objections/concerns are raised by this deadline, please proceed as you propose below. i'm fine with it, but would like a direct cc to timel...@gmail.com, i'll try to read it promptly but can't make any guarantees.
Re: [widgets] Proposal to update Dig Sig spec; deadline May 3
On Tuesday, April 26, 2011 at 5:49 PM, timeless wrote: On Tue, Apr 26, 2011 at 8:50 AM, Arthur Barstow art.bars...@nokia.com wrote: Widget People - if you have any objections/concerns re Marcos' proposal below, please respond by May 3 at the latest. (For some additional context, the start of the thread is [1]). Marcos - if no major objections/concerns are raised by this deadline, please proceed as you propose below. i'm fine with it, but would like a direct cc to timel...@gmail.com, i'll try to read it promptly but can't make any guarantees. Ok, I'll email you as soon as I'm done.
Re: [IndexedDB] Discrepancies with the Event type of error in section 4.12
On Mon, Apr 25, 2011 at 6:12 PM, Jacob Rossi jro...@microsoft.com wrote: I plan on adding wording to D3E to clarify that DOM event propagation could apply to other tree-like structures (like indexedDB objects) [1]. However, I'm not a fan of defining variable behavior for a given event type. Yes, the spec currently does this--but as you accurately point out, just because it was done before doesn't make it right. :-) Most of these inconsistencies in D3E exist to allow for legacy behavior. Take for example, the scroll event (which is the only event in D3E I can think of which has variable bubbling behavior). It's only defined to bubble in certain cases because that's what is (unfortunately) the interoperable behavior. IMO, I think XHR is wrong to overload error like this. There should be a progresserror event--but I suppose that ship has sailed. Alternatively, DOM3 Events could define an additional event type (with a name other than error) which does bubble. That way dependent specifications have a choice of which behavior to adopt. Going forward, I think we should be consistent in defining the interface, bubbling, and cancelling aspects of an event type cross-specifications. We can't correct the world as it is today, but we shouldn't proliferate the discrepancies. I think it's a complicated developer model to have an event bubble only in certain scenarios. I agree consistency is good, but it comes in many flavors. If the event was called progresserror for XHR, then that would mean that you have to listen for error in some places but progresserror in others, for what is essentially the exact same thing. That isn't consistent from a author point of view either. To make matters worse XHR used to use plain Events, but then gained the extra feature of reporting progress by adding additional properties to its various events. So it would have been very messy if we had tried to restrict error to just be plain Events. If we really feel that we must keep consistent with any events that DOM Events spec defines, then DOM Events needs to be a lot more careful about defining events with generic names. Otherwise other specs have to work around DOM Events by arbitrarily using more complex names. This doesn't sound like a win for anyone. / Jonas
Re: [IndexedDB] which names can be the empty string?
I say we should allow the empty string. Apparently there were no specific reason why we added such a check to our code. / Jonas On Tue, Apr 26, 2011 at 6:25 AM, Mark Pilgrim pilg...@google.com wrote: I have no opinion whatsoever, except that the spec should specify it one way or the other so I can close these bugs. :) On Mon, Apr 25, 2011 at 9:35 PM, Jonas Sicking jo...@sicking.cc wrote: Good question. I don't have a strong opinion. It makes sense to me to allow anything. Don't know I there was any reason we added explicit checks. / Jonas On Monday, April 25, 2011, Mark Pilgrim pilg...@google.com wrote: 1. Can an object store be named the empty string? 2. Can an index be named the empty string? Other things, like databases, are allowed to have a name that is the empty string. Mozilla has tests that expect both of the above cases to fail, but as I'm porting those tests to WebKit, it's not clear from my reading of the spec whether those tests are valid. -Mark Pilgrim
Re: [IndexedDB] which names can be the empty string?
OK, I'll close out our bugs on the subject and point to this conversation. Thanks, -Mark On Tue, Apr 26, 2011 at 1:34 PM, Jonas Sicking jo...@sicking.cc wrote: I say we should allow the empty string. Apparently there were no specific reason why we added such a check to our code. / Jonas On Tue, Apr 26, 2011 at 6:25 AM, Mark Pilgrim pilg...@google.com wrote: I have no opinion whatsoever, except that the spec should specify it one way or the other so I can close these bugs. :) On Mon, Apr 25, 2011 at 9:35 PM, Jonas Sicking jo...@sicking.cc wrote: Good question. I don't have a strong opinion. It makes sense to me to allow anything. Don't know I there was any reason we added explicit checks. / Jonas On Monday, April 25, 2011, Mark Pilgrim pilg...@google.com wrote: 1. Can an object store be named the empty string? 2. Can an index be named the empty string? Other things, like databases, are allowed to have a name that is the empty string. Mozilla has tests that expect both of the above cases to fail, but as I'm porting those tests to WebKit, it's not clear from my reading of the spec whether those tests are valid. -Mark Pilgrim
Re: [IndexedDB] Discrepancies with the Event type of error in section 4.12
On Tue, Apr 26, 2011 at 10:20 AM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Apr 25, 2011 at 6:12 PM, Jacob Rossi jro...@microsoft.com wrote: I plan on adding wording to D3E to clarify that DOM event propagation could apply to other tree-like structures (like indexedDB objects) [1]. However, I'm not a fan of defining variable behavior for a given event type. Yes, the spec currently does this--but as you accurately point out, just because it was done before doesn't make it right. :-) Most of these inconsistencies in D3E exist to allow for legacy behavior. Take for example, the scroll event (which is the only event in D3E I can think of which has variable bubbling behavior). It's only defined to bubble in certain cases because that's what is (unfortunately) the interoperable behavior. IMO, I think XHR is wrong to overload error like this. There should be a progresserror event--but I suppose that ship has sailed. Alternatively, DOM3 Events could define an additional event type (with a name other than error) which does bubble. That way dependent specifications have a choice of which behavior to adopt. Going forward, I think we should be consistent in defining the interface, bubbling, and cancelling aspects of an event type cross-specifications. We can't correct the world as it is today, but we shouldn't proliferate the discrepancies. I think it's a complicated developer model to have an event bubble only in certain scenarios. I agree consistency is good, but it comes in many flavors. If the event was called progresserror for XHR, then that would mean that you have to listen for error in some places but progresserror in others, for what is essentially the exact same thing. That isn't consistent from a author point of view either. To make matters worse XHR used to use plain Events, but then gained the extra feature of reporting progress by adding additional properties to its various events. So it would have been very messy if we had tried to restrict error to just be plain Events. If we really feel that we must keep consistent with any events that DOM Events spec defines, then DOM Events needs to be a lot more careful about defining events with generic names. Otherwise other specs have to work around DOM Events by arbitrarily using more complex names. This doesn't sound like a win for anyone. Sorry, forgot to tie this back to IndexedDB. While technically possible to use something other than error here, I think that introduces other inconsistencies for authors. We currently have a very nice success/error pairing which is very intuitive. While we could introduce something like onerror corresponding to addEventListener(idberror) that is IMHO a much worse inconsistency. It also makes things very surprising if pages check event.type since that won't be error. Having asynchronous operations always produce error events, be they network requests or database operations, is another nice consistency we'd loose. Also, in the firefox implementation we dispatch a error event on the window object if the error event isn't cancelled. This is very nice since it ties in to the error handling mechanism that exists today for script errors. I.e. it ties in to the window.onerror property which already exists. This has been discussed on the list and I meant to add this to the spec when we defined error handling, but it looks like I forgot. If we weren't using error when dispatching to the IDB objects, then we'd have a bit of inconsistency here too. Another data point as well is how workers use error events. When code in a worker throws an exception and doesn't catch it, a error event is dispatched against the workers global scope. This is similar to how window.onerror works. If the worker is a deeply nested worker, i.e. a worker in a worker in a worker, then you get an effect similar to a bubbling event. The event is dispatched first to the worker global scope, then to the worker object itself, then to the workers parent worker and then its parent worker and so on. The effect is very much like a bubbling event, but the situation is a bit more complex since all the events are dispatched in different scopes (which are potentially even in different processes, depending on the implementation). So it seems to me that while it's not ideal that different events with the same name (error) can either be bubbling or non bubbling depending which objects the events are dispatched at, it seems like trying to fix that problem results in much bigger problems and much bigger inconsistencies. / Jonas
Re: [IndexedDB] Discrepancies with the Event type of error in section 4.12
On Mon, Apr 25, 2011 at 9:18 AM, Israel Hilerio isra...@microsoft.com wrote: The same question applies to bubbling. What is the intent of bubbling an error? For example, if a developer tries to add an object to an objectStore and he fails, where should the event bubble to: the transaction, the database, etc.? The bubbling hierarchy doesn't seem to be clearly defined. It would be great to clarify the scenarios here. Sorry, forgot to reply to this part. creating object stores never fails asynchronously, so no error events are ever dispatched for that action. This should be defined in spec. / Jonas
Re: [widgets] Widget Updates tests?
Thanks for the update Richard. Is this spec ready for LCWD publication? If not, what remains to be done before it is LC-ready? Also, I would appreciate any implementation data you can share so we can update [1] -Thanks, AB [1] http://www.w3.org/2008/webapps/wiki/WidgetImplementation On Apr/26/2011 11:59 AM, ext Rich Tibbett wrote: Hi Scott, On 28.03.2011 at 15:59, Scott Wilson wrote: Are there any tests available - even informal ones - for the Widget Updates[1] spec? We've just uploaded the Widget Updates test suite to the CVS repository. The Widgets Updates test suite is available here: http://dev.w3.org/2006/waf/widgets-updates/test-suite/ Individual test cases are available at http://dev.w3.org/2006/waf/widgets-updates/test-suite/test-cases/ Once we have some implementer feedback on the tests we'll go ahead and populate the Widget Updates implementation report in the usual way: http://dev.w3.org/2006/waf/widgets-updates/imp-report/ If you have any feedback or questions just let us know. - Rich [1] http://www.w3.org/TR/widgets-updates/
Re: [IndexedDB] Discrepancies with the Event type of error in section 4.12
On Tue, Apr 26, 2011 at 12:00 PM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Apr 25, 2011 at 9:18 AM, Israel Hilerio isra...@microsoft.com wrote: The same question applies to bubbling. What is the intent of bubbling an error? For example, if a developer tries to add an object to an objectStore and he fails, where should the event bubble to: the transaction, the database, etc.? The bubbling hierarchy doesn't seem to be clearly defined. It would be great to clarify the scenarios here. Sorry, forgot to reply to this part. creating object stores never fails asynchronously, so no error events are ever dispatched for that action. This should be defined in spec. should be as in should already be. Feel free to clarify in the spec if there's anything you think is unclear. / Jonas
RE: [IndexedDB] Isolation mode -- edit
I would say without affecting what resulting data is stored in the database. This since the order the events fire in can affect the state of the javascript environment kept by the web page. / Jonas Made the change in the speclet: There is no guarantee about the order that results from requests in different transactions are returned. Similarly, the transaction modes ensure that two requests placed against different transactions can execute in any order without affecting what resulting data is stored in the database. Thanks for your help. E
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?
[Indexeddb} Bug # 9653 - nullable violations on parameters
Did you come up with a conclusion on how to handle null violations: * Bug 9653 [1] - How to handle nullable violations is not specified. I looked for previous threads and couldn't find anything. It seems to me we should throw a NON_TRANSIENT_ERR when a developer uses a null value on a non-nullable parameter. What do you think? Israel [1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=9653
Re: [Indexeddb} Bug # 9653 - nullable violations on parameters
On Tue, Apr 26, 2011 at 6:57 PM, Israel Hilerio isra...@microsoft.com wrote: Did you come up with a conclusion on how to handle null violations: * Bug 9653 [1] - How to handle nullable violations is not specified. I looked for previous threads and couldn't find anything. It seems to me we should throw a NON_TRANSIENT_ERR when a developer uses a null value on a non-nullable parameter. What do you think? Which functions in particular are you referring to? I never really understood the relevant bug as it didn't mention which functions it's about. However in general I think we should reuse WebIDL as much as possible. It used to define a extended attribute [NoNull] which you could specify on an argument and would indicate that the function should throw if a null value was passed. This is useful for for example the second argument in the Node.insertBefore function. However it appears that that extended attribute is not present in newer versions of the WebIDL spec. Cameron, is this something that is planned to be brought back? It seems like a useful feature to avoid having to define in prose this rather common requirement. We should also define which exception should be thrown if such a [NoNull] requirement was violated. / Jonas
Re: [Indexeddb} Bug # 9653 - nullable violations on parameters
Jonas Sicking: However it appears that that extended attribute is not present in newer versions of the WebIDL spec. Cameron, is this something that is planned to be brought back? It seems like a useful feature to avoid having to define in prose this rather common requirement. We should also define which exception should be thrown if such a [NoNull] requirement was violated. I plan to make object types non-nullable by default, and to allow null you would write “MyInterface?”. http://www.w3.org/Bugs/Public/show_bug.cgi?id=10640. I will most likely make passing in null for a non-nullable object type result in a TypeError being thrown. -- Cameron McCormack ≝ http://mcc.id.au/
Re: [Indexeddb} Bug # 9653 - nullable violations on parameters
On Tue, Apr 26, 2011 at 8:23 PM, Cameron McCormack c...@mcc.id.au wrote: Jonas Sicking: However it appears that that extended attribute is not present in newer versions of the WebIDL spec. Cameron, is this something that is planned to be brought back? It seems like a useful feature to avoid having to define in prose this rather common requirement. We should also define which exception should be thrown if such a [NoNull] requirement was violated. I plan to make object types non-nullable by default, and to allow null you would write “MyInterface?”. http://www.w3.org/Bugs/Public/show_bug.cgi?id=10640. I will most likely make passing in null for a non-nullable object type result in a TypeError being thrown. Excellent! I think that should mean that no changes are needed to the IndexedDB spec at all. I can't think of any instances where we use specific interface names while still accepting null values. / Jonas / Jonas
