Re: [whatwg] Progress Events done event
Why is
xhr.addEventListener(done, callCompleteHandler, false);
more concise than
add_done_hook(xhr, cch)?
The former line is actually longer.
While English does not have loops, it has quantifiers and relations that are
quite convenient for most common purposes. I do not think English with
loops would be cool. C has loops but it is not cool at all. It is
doubleplusuncool. Declarative languages are, in general, cooler than
functional ones. You need special languages for special purposes and there
is nothing weird about this fact.
Chris
-Original Message-
From: Garrett Smith [mailto:[EMAIL PROTECTED]
Sent: Monday, September 10, 2007 11:33 PM
To: Křištof Želechovski
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: [whatwg] Progress Events done event
On 8/27/07, Křištof Želechovski [EMAIL PROTECTED] 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: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Garrett Smith
Sent: Sunday, August 26, 2007 8:25 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
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.
--
Programming is a collaborative art.
Re: [whatwg] Progress Events done event
On 8/27/07, Křištof Želechovski [EMAIL PROTECTED] 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: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Garrett Smith
Sent: Sunday, August 26, 2007 8:25 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
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.
--
Programming is a collaborative art.
Re: [whatwg] Progress Events done event
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
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Garrett Smith
Sent: Sunday, August 26, 2007 8:25 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
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.
Re: [whatwg] Progress Events done event
This proposal is similar to the callbacks that Prototype's
Ajax.Requestmakes available. Instead of a done event, it provides
the callback
onComplete: http://prototypejs.org/api/ajax/options
On 8/26/07, Garrett Smith [EMAIL PROTECTED] wrote:
I've noticed a case when developing Ajax apps that I often end up
duplicating a call to hide loading.gif (for example) when the call
is over.
Progress Events
http://dev.w3.org/cvsweb/~checkout~/2006/webapi/progress/Progress.html?rev=1.16content-type=text/html;%20charset=iso-8859-1#XHR
Helps facilitate that, however, I think I see a way that the use case
could be better-accomodated. Here is a simple use-case that
illustrates the problem:
Author loads a large picture.
While the picture is loading, the user sees a progress bar.
When the call is done, the progress bar is hidden.
Notice, the use case is not, when the picture is loaded, remove the
progress bar. Instead, it reads: When the call is done, the progress
bar is hidden.
In this use case, the progress bar must be removed, whether the call
is successful or not. If the call fails, the call is aborted, or the
call is successful, the progress bar is hidden.
To fulfill the use case, the author creates a function callFinished,
for example:
function callFinished( progressEvent ) {
// Remove loader bar.
}
Using the current proposal, the author adds an EventListener for load,
to hide the progress bar when the image is done loading. However, the
author must also add EventListeners for failure and success Events to
remove the loader bar in those cases now.
==
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.
I see this as being analogous to hang up the phone after the call is
done. We all know how that works. It doesn't matter if the other
person hung up on rudely, we both said goodbye, the line got cut off,
the phone service was down -- the call is over. (digression)
It would be useful to have a done event.
The revised example, with a hypothetical done event:
==
function showImage( imageHref ) {
...
// remove the progress bar when done.
image.addEventListener(done, hideProgressBar, false);
}
==
Garrett
Re: [whatwg] Progress Events done event
On 8/26/07, Weston Ruter [EMAIL PROTECTED] wrote: This proposal is similar to the callbacks that Prototype's Ajax.Request makes available. Instead of a done event, it provides the callback onComplete: http://prototypejs.org/api/ajax/options Thanks! This is evidence of a real-world use case in a popular library. (Prototype's callbacks do not appear to be event publishers. Additionally, the w3c Events spec also provides callback-autonomy. One callback's error won't cause failure in the notification system. It is as if it is thrown in a new thread.) Garrett
Re: [whatwg] Progress Events done event
On Sat, 25 Aug 2007, Garrett Smith wrote: I've noticed a case when developing Ajax apps that I often end up duplicating a call to hide loading.gif (for example) when the call is over. Progress Events http://dev.w3.org/cvsweb/~checkout~/2006/webapi/progress/Progress.html?rev=1.16content-type=text/html;%20charset=iso-8859-1#XHR Was this intended as feedback on the Progress Events spec, or the HTML5 spec? If the former, you want to send it to [EMAIL PROTECTED] If the latter, I'm not really sure I follow what you want to change in the spec, could you elaborate? Thanks, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Progress Events done event
- Original Message -
From: Garrett Smith [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Saturday, August 25, 2007 11:24 PM
Subject: [whatwg] Progress Events done event
I've noticed a case when developing Ajax apps that I often end up
duplicating a call to hide loading.gif (for example) when the call
is over.
Progress Events
http://dev.w3.org/cvsweb/~checkout~/2006/webapi/progress/Progress.html?rev=1.16content-type=text/html;%20charset=iso-8859-1#XHR
...
Just as an example of other way of doing this:
In HTMLayout and Sciter (h-smile core) I introduced
:busy state flag in CSS. And DOM element as a class
have request() method [1] that allows to replace content
of the element from remote source or to deliver any
data (e.g. JSON, XML) to the element.
:busy CSS flag is active when some load data request
issued for the element and until it finishes. So to style
in-progress situation is a matter of single
declaration in CSS:
td.bound:busy { background-image:url(progress.gif); }
iframe:busy { foreground-image:url(loading.gif); }
img:busy { foreground-image:url(loading-image.gif); }
Reason of my comment: I think that events
like this should be reflected in CSS state flags too.
CSS is a natural place to deal with this.
Andrew Fedoniouk.
http://terrainformatica.com
[1] http://www.terrainformatica.com/sciter/Element.whtm
