W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2012

Re: [UndoManager] Re-introduce DOMTransaction interface?

From: Yuval Sadan <sadan.yuval@gmail.com>
Date: Thu, 12 Jul 2012 12:07:56 +0300
Message-ID: <CAJaqjSoSdyiH3w5w4rK=7_WxxOOC5dQ=cwiQmUrY2njtnucY_w@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: Ryosuke Niwa <rniwa@webkit.org>, Boris Zbarsky <bzbarsky@mit.edu>, public-webapps@w3.org
> I think we need to realize that a lot of the APIs that have been
> designed in the past aren't terribly good APIs.

The IndexedDB API is rather new, and the manner in which it consistently
uses event handlers on returned objects is rather innovative. The
DOMTransaction object is more similar to that.

> In other words, I think it's more important to focus on what makes a
> good API, than what is consistent with other DOM APIs.
Consistency has its value. Even if some is lacking, fixing it in some
places and not in others might cause a jumble. Which is my feeling actually
about the IndexedDB API. Adding more syntactical variations can lead to
hectic code.
However, I agree that it's not the primary concern.

> Something that I really liked about the old API was the fact that
> using it created very intuitive code. Basically you just write a class
> the way you normally would write a class, and then pass in your
> object:
> x = {
>   someState: 0,
>   apply: function() { this.someState++; this.modifyDOM(); },
>   unapply: function() { this.subState--; this.modifyDOMOtherWay(); },
>   ...
> };
> undoManager.transact(x);

> You can even do things like
> undoManager.transact(createParagraphTransaction(params));
How's that different from:
function createParagrahTransaction(params) {
  x = new DOMTransaction("Create paragraph");
  x.apply = function() { ... use params... };
  x.onundo = function() { ... use params ... };
  return x;

Also, in your example, I think that in the JS-object proposal you won't be
able to reference the original object's properties -- it will be lost, and
'this' is window.

The fact that we have to choose between creating APIs that feel like
> "DOM APIs" or "JS APIs" I think is an indication that "DOM APIs" are
> doing things wrong. There should be no difference between "DOM APIs"
> and "JS APIs".
It is a problem. But WebIDL and JS aren't two of the same.
Received on Thursday, 12 July 2012 09:08:49 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:37 UTC