Autocomplete on text fields inside collections

[LeaVerou]

Autocomplete with values of the same property from other items of the collection.

[karger]

what if I want some other options in the autocomplete that aren't part
of any other item (yet)?

On 02/04/2016 05:30 PM, Lea Verou wrote:

Autocomplete with values of the same property from other items of the
collection.

—
Reply to this email directly or view it on GitHub
https://github.com/LeaVerou/wysie/issues/8.

[LeaVerou]

Any actual use cases in mind?

You would have to type them at least once to add them to the autocomplete, so you may as well type them once to add them as values to the property (which would also add them to the autocomplete). If you don't plan to use them as values to the property, why have them in the autocomplete? As partial values, perhaps? Or maybe that would be useful in cases where the person creating the template is different than the person editing the data (which I expect to be many).

[Dsan10s]

We discussed having the browser achieve this functionality natively, do we still want to go down that path, or code autocomplete manually to have more control?

[karger]

I do not what is this "code manually" of which you speak (and neither will our users).

…

On 4/13/2017 11:15 PM, Danny Sanchez wrote: We discussed having the browser achieve this functionality natively, do we still want to go down that path, or code autocomplete manually to have more control? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#8 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABFpXnxE5PYr0-MfJFAhDoPH0HhlN7Ewks5rvuTcgaJpZM4HT1TW>.

[Dsan10s]

Sorry, what I mean by "code manually" is to make the implementation of autocomplete ourselves, vs using the browser's native autocomplete functionality

[LeaVerou]

If we don't go with native, we don't have to code it ourselves. I have coded a very extensible/customizable autocomplete widget last year which has become very popular (over 5300 stars on Github). I wouldn't recommend any of my own stuff if it wasn't recognized by the community, but in this case it's a mature project used by many, many people. [1]: http://leaverou.github.io/awesomplete/ <http://leaverou.github.io/awesomplete/> Lea Verou ✿ http://lea.verou.me ✿ @LeaVerou

…

On 13Apr, 2017, at 23:38, Danny Sanchez ***@***.***> wrote: Sorry, what I mean by "code manually" is to make the implementation of autocomplete ourselves, vs using the browser's native autocomplete functionality — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#8 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAKu3AKr7equn-f_tOwdFUZ6eL7r_Uxuks5rvuozgaJpZM4HT1TW>.

[karger]

I suspect we will want (to expose to the user) that added flexibility provided by awesomeplere. Autocomplete is something we certainly want but that also is clearly not part of mavo core functionality, so needs to be a plugin. Probably a good use case for thinking about plugin configuration syntax? And libraries for making it easy to code a mavo plugin?

…

On 4/14/2017 1:54 PM, Lea Verou wrote: If we don't go with native, we don't have to code it ourselves. I have coded a very extensible/customizable autocomplete widget last year which has become very popular (over 5300 stars on Github). I wouldn't recommend any of my own stuff if it wasn't recognized by the community, but in this case it's a mature project used by many, many people. [1]: http://leaverou.github.io/awesomplete/ <http://leaverou.github.io/awesomplete/> Lea Verou ✿ http://lea.verou.me ✿ @LeaVerou > On 13Apr, 2017, at 23:38, Danny Sanchez ***@***.***> wrote: > > Sorry, what I mean by "code manually" is to make the implementation of autocomplete ourselves, vs using the browser's native autocomplete functionality > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub <#8 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAKu3AKr7equn-f_tOwdFUZ6eL7r_Uxuks5rvuozgaJpZM4HT1TW>. > — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#8 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABFpXuC4ofq_E9_4OPNebUFsYsGXoyDiks5rv8DwgaJpZM4HT1TW>.

[LeaVerou]

David, the idea was that people will automatically get autocomplete for the other values of the same property. They wouldn't have to know or care how that autocomplete was implemented.
And yes, it may be a good idea to have it as a plugin, especially if we don't use the browser's native functionality.

Btw, if people want to use the browser functionality, I realized later they can do it themselves, via existing Mavo functionality:

<div property="foo" mv-edit-list="foo"></div>

and then somewhere in the page:

<datalist id="foo">
    <option property="fooAutocomplete" mv-multiple mv-value="unique(foo)">
</datalist>

I should probably add a demo or docs about this.

[LeaVerou]

So, since this is already possible with expressions, I'm inclined to close this, unless you guys disagree.

[karger]

sure. we can later explore the awesomplete plugin as a way to support more powerful autocomplete.

…

On 4/14/2017 3:08 PM, Lea Verou wrote: So, since this is already possible with expressions, I'm inclined to close this, unless you guys disagree. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#8 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABFpXv3xt4xOtOHWRxo1XjS-ScAJP6QQks5rv9I9gaJpZM4HT1TW>.