RE: [contacts] PutForwards for complex contact attributes

Hi Marcin,

On Tues 19th Jan 2010 at 12:53, Marcin Hanclik wrote:
> 
> Hi Richard,
> 
> I think PutForwards is specified quite well, you just try to 
> overload it, probably too much.
> 

I tend to agree that when we get to Array objects PutForwards falls over
a bit.

> > interface ContactField {
> >     attribute DOMString[]? types;
> >     attribute DOMString    value;
> > };
> > interface ContactProperties {
> >     ...
> >     [PutForwards=value] readonly attribute ContactField[] phones;
> >     ...
> > };
> >
> 
> Your proposal assumes that the value of "value" is set on the 
> newly added array element only.

Hence the problem, it should suggest that value is set on the 'value' of
a newly created array element.

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

This new extended attribute makes sense when using PutForwards with
Arrays.

> 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".
> 

This is as per the WebIDL spec. When I add attributes to a Contact
object that all happens client-side in the browser, denoting that the
PutForwards mechanism should be implementable in standalone JS. I wonder
if/how it is possible to implement a PutForwards mechanism in JS though.
Perhaps it has something to do with listening for variable change events
or binding a function to variable assignments but the solution doesn't
stand out for me.

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

The newly added array item is of type Object. ContactField has no
interface and is included for the definition of valid attributes that
can be provided in this method parameter (i.e. if an Object's attribute
maps to an understood ContactField property then it will be parsed and
used to create the resulting search filter else the attribute will be
ignored).



So how to proceed? I propose dropping the use PutForwards for now
(despite its best intentions), discussing the issue on the WebIDL
mailing list and potentially bringing this back to a future version of
the API when it is more mature / makes more sense.

In the mean time perhaps we should leave helper methods out and consider
what helper methods we may need in this space after FPWD.

Thanks,

Richard


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

*********************************
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.
********************************

Received on Tuesday, 19 January 2010 13:48:05 UTC