Confirmed users
99
edits
Labs/F1/Modularity/WebMod-API: Difference between revisions
tweaks to getAutocompleteEntries
(update getShareCharacteristics()) |
(tweaks to getAutocompleteEntries) |
||
| Line 46: | Line 46: | ||
; shareTypes[].showTo: Can be derived from whether the 'toLabel' field exists. | ; shareTypes[].showTo: Can be derived from whether the 'toLabel' field exists. | ||
=== getAutocompleteEntries(user_info, send_to, to_prefix, callback) === | === link.send.getAutocompleteEntries(user_info, send_to, to_prefix, callback) === | ||
Get all the autocomplete entries for the "to" field based on the current setting of the "send to" field for the specified user. For example, the facebook app might return the list of all groups you are a member of if send_to="group wall", and twitter would send a list of all your followers for send_to="direct". | Get all the autocomplete entries for the "to" field based on the current setting of the "send to" field for the specified user and the text currently entered in the 'to' field. For example, the facebook app might return the (filtered) list of all groups you are a member of if send_to="group wall", and twitter would send a (filtered) list of all your followers for send_to="direct". | ||
There is no concept of "paging" the results as it seem unlikely users will actively "page" an auto-complete list - instead they should focus on providing a shorter list of relevant results. | |||
The size of the returned list is not constrained by this method, but WebMods will be encouraged to keep the result list to a reasonable (but relevant) size, or risk offering a poor UX for users of that service. | |||
If the above size restrictions are a problem, we probably need to add the concept of a "chooser ui" which is different from the auto-complete UI? | |||
NOTE: This method exists as a way to avoid introducing a full-blown Contacts | |||
concept and the complexity that would involve. However, a key downside is | |||
that cross-service sharing of this information becomes impossible - eg, if 2 | |||
different services provide email addresses, nothing in this spec allows F1 | |||
to notice that fact and reuse the email addresses for all services which | |||
support sending emails. | |||
NOTE: This might need fine-tuning for performance reasons - currently F1 uses | |||
a cache of contacts, but the technique described here probably needs one | |||
call per character typed. I guess we can still make the caching (or lack | |||
thereof) the responsibility of the service itself (so while we may still make | |||
one call per character typed, that call need not result in network activity) | |||
=== send(user_info, data) === | === send(user_info, data) === | ||
Send an item as described by "data" - ie, perform the actual share. | Send an item as described by "data" - ie, perform the actual share. | ||