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

Re: FileAPI Feedback

From: Garrett Smith <dhtmlkitchen@gmail.com>
Date: Fri, 14 Aug 2009 11:44:22 -0700
Message-ID: <c9e12660908141144k27bec527j5b783e432dff4384@mail.gmail.com>
To: arun@mozilla.com
Cc: WebApps WG <public-webapps@w3.org>
On Wed, Aug 12, 2009 at 6:52 AM, Arun Ranganathan<arun@mozilla.com> wrote:
> Garrett Smith wrote:
>>
>> In glancing at some of the methods in FileAPI, I noticed some coding
>> errors.
>

>>
>> The "status code" and a "getData" method could be designed as
>> properties of one object.
>>

Replace the callback's parameter list with a whole object.

function handleURL(ev) {
  if(ev.hasError) {
    handleError(ev);
  } else {
    handleSuccess(ev);
  }
}

function handleError(ev) {
  var error = ev.error;
  // etc.
}

function handleSuccess(ev) {
  var data = ev.getData();
  // etc.
}

>
> 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 :-)
>

You can run it through JS Lint or use a proper IDE and it will catch
the errors. JS Lint is noisy and will report "Problems" like:-

| The body of a for in should be wrapped in an
| if statement to filter unwanted properties
| from the prototype.

You could try testing it. This would require a test framework that can
handle async firing. Then create a mock object that calls the callback
asyncrhonously. That object can be designed configurable to throw
errors, so that the the mock object throwin errors can facilitate
testing the error conditions.

> -- A*
>
>
Received on Friday, 14 August 2009 18:45:03 GMT

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