W3C home > Mailing lists > Public > public-device-apis@w3.org > January 2010

RE: [contacts] PutForwards for complex contact attributes

From: Marcin Hanclik <Marcin.Hanclik@access-company.com>
Date: Tue, 19 Jan 2010 13:52:44 +0100
To: "richard.tibbett@orange-ftgroup.com" <richard.tibbett@orange-ftgroup.com>, "public-device-apis@w3.org" <public-device-apis@w3.org>
Message-ID: <FAA1D89C5BAF1142A74AF116630A9F2C28944D9D32@OBEEX01.obe.access-company.com>
Hi Richard,

I think PutForwards is specified quite well, you just try to overload it, probably too much.

> interface ContactField {
>     attribute DOMString[]? types;
>     attribute DOMString    value;
> };
> interface ContactProperties {
>     ...
>     [PutForwards=value] readonly attribute ContactField[] phones;
>     ...
> };
>
If instead you define ContactProperties as:

    [PutForwards=value] readonly attribute ContactField phones; //note that phones is not an array anymore

then it would work, i.e.
contact.phones = '+440000000001'; // ...set the "value".

The other meaning could be that behind

    [PutForwards=value] readonly attribute ContactField[] phones; //note that phones is an array again

the "value" attribute would be the attribute of the array and not of the ContactField interface.

Your proposal assumes that the value of "value" is set on the newly added array element only.
There is a lot of semantics behind that in my opinion, far more that in the original PutForwards.
I think we need to take into account also the following potential wishes / understandings :
- setting the value of the attribute for all elements in the array
- setting the value of the attribute of the array itself (as above).

I think that for your case we need new extended attribute, something like:
[PutForwardsForNewlyAddedElementOfTheArray=...] or so.

What actually adds more complexity to the topic is that

> contact.phones.push({value:'+440000000001'});

assumes that the newly added array item is of ContactField type.
Actually it is not doable on the fly with WebIDL / ES as they are, I think.
The "type" is a complex topic in ES.
We would need far more documentation about it.
I think we would need to define the link also to the [[Class]] internal property (ECMAScript 5 changed it a bit vs. 3rd Edition).

Thanks,
Marcin

Marcin Hanclik
ACCESS Systems Germany GmbH
Tel: +49-208-8290-6452  |  Fax: +49-208-8290-6465
Mobile: +49-163-8290-646
E-Mail: marcin.hanclik@access-company.com

-----Original Message-----
From: public-device-apis-request@w3.org [mailto:public-device-apis-request@w3.org] On Behalf Of richard.tibbett@orange-ftgroup.com
Sent: Tuesday, January 19, 2010 1:21 PM
To: public-device-apis@w3.org
Subject: RE: [contacts] PutForwards for complex contact attributes

Hi,

I'm of the current belief having studied the subject somewhat that
WebIDL PutForwards [1] is not implementable within the Javascript
language. I hope to be stood corrected ;-)

I'm also still at a loss as to if/how to correctly define PutForwards on
an array object in WebIDL. Any input would be excellent as it avoids
requiring set and get methods in a JS API to mimic the 'putforwards
effect'.

If anyone is able to propose a way to implement the existing WebIDL
PutForwards mechanism [1] in a JS environment then that would be great
(and would be kudos for genius!). Otherwise we should drop this
PutForwards proposal albeit that would come at the loss of some
intuitive and useful helper behaviour and may require some helper
functions to be defined.

Cheers,

Richard

[1] http://dev.w3.org/2006/webapi/WebIDL/#PutForwards

> -----Original Message-----
> From: public-device-apis-request@w3.org
> [mailto:public-device-apis-request@w3.org] On Behalf Of
> richard.tibbett@orange-ftgroup.com
> Sent: 21 December 2009 17:11
> To: public-device-apis@w3.org
> Subject: [contacts] PutForwards for complex contact attributes
>
> Hi,
>
> Looking in to the WebIDL documentation I see some value in
> using PutForwards [1] for Contacts API [2] 'complex' attributes.
>
> The intention is to increase the simplicity for developers to
> work with ContactField-based attributes (e.g. currently these
> are phones, emails, impps attributes in the Contact interface):
>
> The intention is for...
>
> contact.phones.push({value:'+440000000001'}); // add a new
> value, relying on the existing mechanism
>
> ...to become equivalent to:
>
> contact.phones.push('+440000000001'); // ...add a new value,
> relying on a PutForwards helper mechanism to set the
> resulting 'value' attribute to '+440000000001'.
>
>
> My question is a.) whether this is of interest for this API,
> and b.) how it can be correctly defined in WebIDL based on
> the nature of the attribute (an Array).
>
> Currently I have the following markup in mind:
>
> interface ContactField {
>     attribute DOMString[]? types;
>     attribute DOMString    value;
> };
> interface ContactProperties {
>     ...
>     [PutForwards=value] readonly attribute ContactField[] phones;
>     ...
> };
>
> Is this specified correctly???
>
> This could require clarification via the WebIDL mailing list
> but worthwhile getting feedback from DAP participants on the
> proposed helper mechanism first...
>
> Best Regards,
>
> Richard
>
> [1] http://dev.w3.org/2006/webapi/WebIDL/#PutForwards
>
> [2] http://dev.w3.org/2009/dap/contacts/
>
>

*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees.
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration.
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************



________________________________________

Access Systems Germany GmbH
Essener Strasse 5  |  D-46047 Oberhausen
HRB 13548 Amtsgericht Duisburg
Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda

www.access-company.com

CONFIDENTIALITY NOTICE
This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the
individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited.
If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.
Received on Tuesday, 19 January 2010 12:53:23 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:41 UTC