W3C home > Mailing lists > Public > public-webapi@w3.org > September 2007

Re: Re: [whatwg] Progress Events "done" event

From: Garrett Smith <dhtmlkitchen@gmail.com>
Date: Sat, 15 Sep 2007 13:11:17 -0700
Message-ID: <c9e12660709151311v22580613g92dc72ba55862ce4@mail.gmail.com>
To: "Web API public" <public-webapi@w3.org>
On 9/10/07, Charles McCathieNevile <chaals@opera.com> wrote:
> Forwarded and reply-to set to webapi-public, which is where you should
> send things you want actively considered for the W3C progress events spec.
> That's the group working on the spec.
>
I had a mistake. Thank you.

> I think there is enough detail left in the mail below for webAPI people to
> get this. The idea is that it might be helpful to add a "done" event that
> could be trapped instead of having to get the seperate possible events
> that mean you are done.
>
Correct.

> I'm inclined not to add a "done" event. It invites code repetition in the
> browser, which is not helpful in the case of mobile browsers.
Actually, having a "done" event avoids repetition by allowing the
author to address the completion aspect singularly, thus avoiding
having to use a loop or copy-pasting code blocks to
success/failure/abort.

Also, I
> think the example doesn't take into account that where the load is
> aborted, or wherer there is an error, you often want to pass by some
> relevant function such as explain what happened before calling the code to
> clean up the progress bar.
>
It sounds like you are suggesting a use case that introduces a timing
sequence. Let me see if I understand you correctly:
Bad Path (error)
1. call fails
2. show error msg for a brief period.
3. when the error msg hides, hide the progress bar.

Is this what you mean?

In that case, a 'done' event would not be suitable.

However, in the following use case:
Bad Path (Error)
1. call fails.
2. remove progress bar and immediately show an error.

or:
Bad Path (Error)
1. call fails
2. replace progress bar with error msg


If success and abort had similar functionality, the developer could
add a second callback to each completion event. A 'done' event would
not be necessary:

var doneEvents = ["error", "abort", "load"];

doneEvents.forEach( function( type ) {
    image.addEventListener( type, hideProgressBar, false );
});

function hideProgressBar( progEv ) {
    document.getElementById("progressBar")
}

A done event would allow the developer to add only one eventListener
to remove the progress bar when the event was done.

If used properly, it would be used to avoid repetition (concise,
explicit). For example:
image.addEventListener( "done", hideProgressBar, false );

It would be a VERY BAD use of a done event:

image.addEventListener( "done", checkCallDone, false );
function checkCallDone( progEv ) {
    switch( progEv.type ) {
        case "load" :
        // do something specific.
       break;
    }
}

It is no doubt that someone would eventually do this. It is impossible
from preventing people from programming badly. Is this a reason for
omitting it from the API?

Charles, if I've misunderstood you, please explain. I am not trying to
set up a straw man.

Garrett

> Since progress events are used by other specs, they can add a done if they
> really want. But it turns out that for example XHR has onreadystate change
> which you can use to get the same info.
>
> What do others think?
>
> Cheers
>
> Chaals
>
> ------- Forwarded message -------
> From: "Garrett Smith" <dhtmlkitchen@gmail.com>
> To: "Křištof Želechovski" <giecrilj@stegny.2a.pl>
> Cc: whatwg@whatwg.org, chaals@opera.com
> Subject: Re: [whatwg] Progress Events "done" event
> Date: Mon, 10 Sep 2007 23:33:20 +0200
>
> On 8/27/07, Křištof Želechovski <giecrilj@stegny.2a.pl> wrote:
> > Remember that JavaScript is a programming language after all.  You can
> > use a
> > loop to get rid of the repetitions.
> > Start from
> > var done = ["load", "error", "abort"]...
> > and apply the closure image.aEL(?, hPB, false) to it.
> > Sincerely,
> > Chris
> >
> That is true, in fact, it would also be possible to use Array.forEach
> on that array.
>
> The disadvantage is that it still invites code repetition. It is less
> concise.
>
> On the contrary:
>
> xhr.addEventListener("done", callCompleteHandler, false);
> function callCompleteHandler(e) {
>
> }
>
> Translates the use case to code quite naturally.
>
>
> I like to make these examples that are conceptually similar:
>
> "I'm going to call my friend and then I'm going to the dry cleaner."
> vs.
>
> "I'm going to call my friend and if she's not available, after that,
> I'm going to the dry cleaner and if the call failed, after that, I'm
> going to the dry cleaner, and if we talk for a bit, after that...
>
> You get the point. English doesn't have loops or generators (hey
> wouldn't that be cool!).
>
> My point is that having a done event is more concise and makes
> realizing the use-case requirement to code more explicit.
>
> Garrett
>
> > -----Original Message-----
> > From: whatwg-bounces@lists.whatwg.org
> > [mailto:whatwg-bounces@lists.whatwg.org] On Behalf Of Garrett Smith
> > Sent: Sunday, August 26, 2007 8:25 AM
> > To: whatwg@whatwg.org
> > Cc: chaals@opera.com
> > Subject: [whatwg] Progress Events "done" event
> >
> >
> > ==========================================
> > function showImage(imageHref) {
> > ...
> >
> > // remove the progress bar when done.
> >        image.addEventListener("load", hideProgressBar, false);
> >        image.addEventListener("error", hideProgressBar, false);
> >        image.addEventListener("abort", hideProgressBar, false);
> > }
> > ==========================================
> >
> > This is somewhat verbose. Clearly, the author is forced to repeat
> > himself when all he really wants to do is hide the progress bar after
> > the call is done.
> >
> >
> >
> >
> >
>
>
>
> --
>    Charles McCathieNevile, Opera Software: Standards Group
>    hablo español  -  je parle français  -  jeg lærer norsk
> chaals@opera.com   http://snapshot.opera.com - Kestrel (9.5α1)
>


-- 
Programming is a collaborative art.
Received on Saturday, 15 September 2007 20:11:28 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:18:58 GMT