canmove, Confirmed users
2,887
edits
WebAPI/ContactsAPI: Difference between revisions
Jump to navigation
Jump to search
→API: add a forward/backward compat "pref" field to ContactField to simplify "type", be ready for vCard4 and compat with vCard3
(FAQ: Should the ContactsAPI data model change for DAP Contacts (no), and more details) |
(→API: add a forward/backward compat "pref" field to ContactField to simplify "type", be ready for vCard4 and compat with vCard3) |
||
| Line 52: | Line 52: | ||
interface ContactField : nsISupports | interface ContactField : nsISupports | ||
{ | { | ||
attribute DOMString[] type; // | attribute DOMString[] type; // "home", "work", etc. | ||
attribute DOMString value; | attribute DOMString value; | ||
attribute integer pref; // 0 = no pref, 1 = preferred (vCard3 type:PREF) | |||
}; | }; | ||
| Line 62: | Line 63: | ||
interface ContactAddress { | interface ContactAddress { | ||
attribute DOMString[] type; // | attribute DOMString[] type; // "home", "work", etc. | ||
attribute integer pref; // 0 = no pref, 1 = preferred. | |||
attribute DOMString streetAddress; | attribute DOMString streetAddress; | ||
attribute DOMString locality; | attribute DOMString locality; | ||
| Line 101: | Line 103: | ||
readonly attribute Date updated; | readonly attribute Date updated; | ||
}; | }; | ||
The integer 'pref' field has been added for compatibility with both vCard3 and vCard4 use of 'pref'. | |||
* 0 = no preference, same as if unspecified in vCard3 or vCard4. | |||
* 1 = preferred, same as type:PREF in vCard3 and PREF:1 in vCard4 | |||
* 2-100 = reserved. Implementations may treat as "1". | |||
* other integer values are invalid and implementations must ignore them. | |||
Note: despite [[hCard2]] including a flat set of adr properties into the top level h-card object for ease of publishing, this interface always abstracts those properties into a ContactAddress sub-object since typical device address books cluster address information accordingly, e.g. for a home or work address. The interface is able to represent published data. | Note: despite [[hCard2]] including a flat set of adr properties into the top level h-card object for ease of publishing, this interface always abstracts those properties into a ContactAddress sub-object since typical device address books cluster address information accordingly, e.g. for a home or work address. The interface is able to represent published data. | ||