move autocomplete list rendering to client side

[johndoh]

Moving the rendering of the autocomplete address list used in compose to the client side allows skins to handle it and offer different layouts for different sized screens. Before I spend too much time on this I wanted to submit this draft to see if the idea was worth pursuing.

There are some hurdles. There is the contact_search_name config var which has to be respected. The server side needs to know about it so it can return the correct fields in the request but rendering those is a client side task because of screen size. Also contact_search_name does not support HTML and I think that's correct, it could be abused. May be having a configurable display for normal screens and a fixed one for small screens is enough.

Example of how the new small screen layout looks:

The proposed rcube_webmail.ksearch_results_display() and rcube_webmail.ksearch_results_highlight() JS functions can be overridden by skins/plugins if required but the stock version maintain the current functionality plus a new layout for smaller screens.

I think ultimately all the text rendering code should be removed from rcube_addressbook::compose_search_name() and instead only the fields returned with the rendering moved into app.js.

This might help with #9329 and #9219.

[alecpl]

We should consider removing contact_search_name option. Maybe we can replace it with autocomplete_extra_field or something. This way the result would contain at most 3 items: "email", "display" (contact name), "extra" (e.g. department name). The extra text could be displayed not inline, but maybe aligned to the right, and only if there's room.

We can consider displaying "two line" records on a big screen too. Gmail does that.

[johndoh]

I like the idea of scrapping contact_search_name. The autocomplete_extra_field, I think it would make sense if that could only be 0 or 1 fields and then skins have a fixed layout to support. If devs want more fields or more customisation then they could do it via the plugin API because its not only about the fields but also the layout. Does that sound acceptable?

Do we really need autocomplete_extra_field even, could addressbook_name_listing be used/improved so that if you wanted say firstname lastname (department) its shown the same in the autocomplete and the contact list? Then in autocomplete the email address would be on the second line and that's the only difference with the contacts list. It could use similar logic as that currently used for displaying contact_search_name so no existing configurability would be lost.

Off the top of my head I'm thinking a plugin hook in rcube_addressbook::compose_search_name() for the returned fields/values and then use the proposed (or similar) new JS functions to construct the entry.

[alecpl]

Makes sense.

[johndoh]

I have replaced contact_search_name with contactlist_name_template which applies in the contact list and the autocomplete, anywhere addressbook_name_listing is used. I did not change addressbook_name_listing because of its use in the settings screen.

eef8919 I modified the ACL plugin to use the new autocomplete but I do not have a working LDAP setup so I cannot test this change, please could someone who uses this plugin confirm the autocomplete still works?