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

Re: FileAPI Feedback

From: Arun Ranganathan <arun@mozilla.com>
Date: Wed, 12 Aug 2009 06:52:18 -0700
Message-ID: <4A82C912.6060408@mozilla.com>
To: Garrett Smith <dhtmlkitchen@gmail.com>
CC: WebApps WG <public-webapps@w3.org>
Garrett Smith wrote:
> In glancing at some of the methods in FileAPI, I noticed some coding
> errors. 
>   
There definitely were errors; thank you for catching them.
> First, an overview explanation:
> http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.xhtml#dfn-getAsDataURL
> |... If the call is successful, implementations MUST
> | call the callback function with a string argument
> | that is a valid data URL [RFC2397], and with a SUCCESS
> | error code on the FileError object...
>
> What is a SUCCESS error code? It sounds like SUCCESS is a "status"
> code that would not be an error. I also understood from your prior
> post that the errorHandler parameter was gone, yet I still see that in
> the example code below.
>   
SUCCESS is in fact a status code, and the rest of the codes correspond 
to errors.  I think calling it an error code is misleading, so I'll 
endeavor to fix that.  In a previous post, I said that the error 
callback was gone, and that now error handling for the asynchronous data 
accessors was via the FileError object used on the callback as an argument.
> The "status code" and a "getData" method could be designed as
> properties of one object.
>   
I'm not sure I understand.  Which object do you mean here?
>
> |// (GS) What is the second parameter "error"?
> | function handleURL(fileAsDataURL, error)
> |
This is the FileError object, used as an argument on the callback to 
report errors.
> | // (GS) best to keep this on local Variable object,
> | // not assigning to window.status.
>   
Good catch -- thank you :-)

-- A*
Received on Wednesday, 12 August 2009 13:53:05 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:33 GMT