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

Re: [File API] feedback on August 1/5 draft

From: Jonas Sicking <jonas@sicking.cc>
Date: Mon, 10 Aug 2009 18:09:45 -0700
Message-ID: <63df84f0908101809p33d65db4maf98062872e0e3fa@mail.gmail.com>
To: Anne van Kesteren <annevk@opera.com>
Cc: WebApps WG <public-webapps@w3.org>
On Sat, Aug 8, 2009 at 6:25 AM, Anne van Kesteren<annevk@opera.com> wrote:
>>>> It seems useful to use the same code for people that want to display
>>>> error messages to the user, this way you can either pass the value in
>>>> the DOM event or from an exception to the same function.
>>>
>>> If you use the same constant name you can still do that.
>>
>> I don't understand. The use case is:
>>
>> A page has a function to deal with displaying error messages to the
>> user. The function looks something like:
>>
>> function displayError(errorNumber) {
>>  var errorString = getLocalizedErrorMessage(errorNumber);
>>  document.getElementById("errorMessage").nodeValue = errorString;
>>  errorDialog.classList.add("displayed");
>>  cancelTimeout(gErrorUITimeout);
>>  gErrorUITimeout = setTimeout(hideError, 5000);
>> }
>
> If instead of errorNumber you passed the object you could do things like
>
>  if (obj.SECURITY_ERR == obj.code) {
>     ...
>  }
>
> which is what I meant.

This seems like a very strange way of sending strings but sending them
encoded as a number and a enumerated string-bundle. I.e. we provide
the author with a code number, but then ask him/her to compare it
against some other numerical values accessed by name, rather than
simply make the number useful. In addition, it means that you can't
use switch statements or hash lookups to implement
getLocalizedErrorMessage above.

> Also, I'll note that you carefully snipped my inconsistency argument!

Sorry, my mistake. I do agree that the values should be moved into the
interface. I don't even think it's proper WebIDL as it is now.

/ Jonas
Received on Tuesday, 11 August 2009 01:10:44 GMT

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