Re: FileAPI Feedback

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:
> |... 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 UTC