Difficulty with data-multiple

[gersonvan]

Hi everyone,

I'm facing difficulties using data-multiple. During the last week I've been trying several approaches to make it work with no sucess.

I'm listing the content, but it is not inserting the comma and giving the option of a new select.

I've added in my application.js the following:

new Awesomplete('input[data-multiple]', { filter: function(text, input) { return Awesomplete.FILTER_CONTAINS(text, input.match(/[^,]*$/)[0]); }, replace: function(text) { var before = this.input.value.match(/^.+,\s*|/)[0]; this.input.value = before + text + ", "; } });

and in my _form.html.erb for this input, I'm using:

<%= f.text_field :objeto_de_acao, :class => 'awesomplete', :list => 'objetos', :data => { :multiple => ''} %> <datalist id="objetos"> <% action_objects_array.each do |action_object| %> <option><%= action_object[0].to_s %></option> <%end%> </datalist>

For what I've seen in the advanced examples, this is all I probably need to do. Am I missing anything?

thanks ins advance.

[vlazar]

You must not use class="awesomplete" on input when you instantiate Awesomplete with JS. All inputs with class="awesomplete" will be automatically initialized by Awesomplete with default behavior. Hence custom filter and replace methods are not working.

[LeaVerou]

@vlazar I would consider this a bug, as it's very unexpected behavior. If someone re-initializes an awesomplete, we should destroy the old object and create a new one with their new settings.
We should also be careful to check if an input is already awesompleted (:P) before we auto-initialize it.
Basically, from the user's perspective, auto-initialization should have the lowest priority, regardless of when the user manually initialized. Auto-initialization exists so that authors that don't know JS can still use this library. This inclusiveness should never get in the way of people that do know JS though.

[vlazar]

@LeaVerou Agree, this behavior is misleading. So what you are suggesting is to keep a list of already awesompleted inputs and add a new destroy method to API?

Related discussion #16868

[vlazar]

I'm also a little bit worried about automatically destroying existing Awesomplete instances. Since we can't control how it was initialized, should we just destroy old instances?

Imagine the instance was created with JS. Then some awesomplete-* event handlers attached. Should we remove those handlers as well when we re-initialize Awesomeplete with different set of options? I mean, those handlers may or may not be directly related to autocompleter itself. Won't the automatic destroy be also misleading in such cases?

[LeaVerou]

Don't we already put an awesomplete property on the inputs that points to the instance? I believe there was a feature request for that a while ago. If so, we don't need a map. If not, we can add it and shoot two birds with one stone.

A destroy() method is needed anyway, and I believe it has been requested in the past as well.

Not sure I get what you mean about events. We have no way of knowing what user event listeners there are, so not sure how you propose removing them, even if we did agree that it would have been a good idea.

[vlazar]

Don't we already put an awesomplete property on the inputs that points to the instance? I believe there was a feature request for that a while ago. If so, we don't need a map. If not, we can add it and shoot two birds with one stone.

There was a tiny PR #16868 but you opposed adding a property to inputs #16868 (comment)

Not sure I get what you mean about events. We have no way of knowing what user event listeners there are, so not sure how you propose removing them, even if we did agree that it would have been a good idea.

I mean additional event handlers may add some functionality to the autocompleter itself (extend it). For this case we probably want to remove those event handlers when we automatically destroy existing instances.

Or event handler may be just a way to communicate with some unrelated component on the page. In that case it's not belong to autocompleter itself and should not be automatically removed.

Sadly we can't tell if event handler is part of custom autocompleter component or not. That's why I'm worried about automatic destroy. This may as well become confusing for some people.

[gersonvan]

Guys, thanks for the help...

It worked some time ago, I was in a hurry and I forgot to come back here to thank you.
Congratulations for the Awesomplete, please keep it running.

bye!