W3C home > Mailing lists > Public > public-device-apis@w3.org > December 2009

RE: [contacts] Comments on editors draft of Contacts API

From: <richard.tibbett@orange-ftgroup.com>
Date: Thu, 3 Dec 2009 16:51:42 +0100
Message-ID: <355A518BC0575547B2A3D6773AAF8EEF6CB0F1@ftrdmel1>
To: <robin@robineko.com>, <dom@w3.org>
Cc: <public-device-apis@w3.org>
Hi,

I want to pick up this thread in an effort to settle the structure for
this API.

Continued below...

br/ Richard

On 30th Nov 2009 at 17:27, Robin Berjon wrote:
> 
> On Nov 30, 2009, at 11:21 , Dominique Hazael-Massieux wrote:
> > * all the interfaces defined in the API are annotated with 
> > [NoInterfaceObject] [2] ; I think it's may make sense for 
> the Contacts 
> > interface depending on the mechanism used to secure the 
> access to the 
> > addressbooks, it's probably not appropriate for many of the other 
> > interfaces; for instance, I don't see how one would add a contact 
> > right now, since one cannot instantiate the Contact interface; was 
> > there a rationale for hiding the interface object? Maybe 
> some of the 
> > interfaces can/should remain hidden through convenience 
> functions, but 
> > they're not defined in the API right now
> 
> Actually, it could work without an interface (and whenever we 
> can do without these we should - keep in mind that they 
> pollute the global namespace). We could just have:
> 
>   var c = myContacts.add({ name: "Pink Unicorn", urls: 
> ["http://shiny-donkey.com/"]});
> 
> The object that is passed is essentially treated as a Contact 
> object - there is no need to create it. Functionally we get 
> the same thing, without pollution. It's much cleaner.
> 

The latest Contacts API draft introduced a Constructor pattern in the
latest editor's draft in an effort to simplify and unify the add/update
and removal of Contact objects from a user's address book.

IMO it is a cleaner approach to the factory pattern in this instance as
it does not require developers to deal in Object literals. Also it is
much harder to get the creation of a new Contact object wrong with such
a Constructor (i.e. its boring but its safe).

The drawback is concern over polluting the global namespace, which I do
agree can lead to problems. 


So, in order to not pollute the global namespace, could we keep the
Constructor pattern but constrain this to our device namespace?
Something like this:

var newContact = new navigator.device.contacts.Contact('Pink Unicorn');

...rather than reverting to this...

var newContact = navigator.contacts.add({name: {formatted: 'Pink
Unicorn'}});


FWIW, the constructor model was copied from the File API [1].

I'd be interested to hear which pattern people would prefer to implement
and develop against. 

Functionally they result in the same thing but the updates to the spec
are not trivial so I'd prefer to get some further discussion on the
list.


Thanks, Richard

[1] http://dev.w3.org/2006/webapi/FileAPI/#filereader-interface
Received on Thursday, 3 December 2009 15:52:26 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:14:02 GMT