Support no jQuery with Awesomplete

[Qouagga]

It's m'y first pull request to another project. I hope I don't do a mistake. I add a js file to support this bundle without jQuery with the library Awesomplete. I change the documentation to explain this add.

[Qouagga]

I don't need. With the replace fonction of Awesomplete, I put the name of the suggestion in the fake input and I put the id of the suggestion in the input read by Symfony. With this, I don't need to create another request "url_get" to get the id with the name.

[Qouagga]

I'm a Symfony dev junior. May be, it s a mistake. But I don't understand why you don't put directly the id in the true input ?

In your file autocompleter-jqueryui.js, line 22 you put the value in the true input.

$fakeInput.autocomplete({
                source: settings.url_list,
                select: function (event, ui) {
                    event.preventDefault();

                    $this.val(ui.item.value); // why no put id ?
                    $(this).val(ui.item.label);
                    if (settings.on_select_callback) {
                        settings.on_select_callback($this, event, ui);
                    }
                },
                minLength: settings.min_length
            });
            if ($this.val() !== '') {
                $.ajax({
                    url: (settings.url_get.substring(-1) === '/' ? settings.url_get : settings.url_get + '/') + $this.attr('value'),
                    success: function (name) {
                        $fakeInput.val(name);
                    }
                });
            }

I think, it's more efficient to put directly the id there. You don't need a second request to search the Id with the label.

$fakeInput.autocomplete({
                source: settings.url_list,
                select: function (event, ui) {
                    event.preventDefault();
                    $this.val(ui.item.id); 
                    $(this).val(ui.item.label);
                    if (settings.on_select_callback) {
                        settings.on_select_callback($this, event, ui);
                    }
                },
                minLength: settings.min_length
            });

With this change, you could remove the option url_get and gain one request to do the same things. May be, I don't see the backfire of this method.

[garak]

I'm a Symfony dev junior. May be, it s a mistake. But I don't understand why you don't put directly the id in the true input ?

When you display the form (e.g. the form is not submitted and it contains pre-filled data), the id is already inside the true input. But I don't want to see the id, I want to see the associated name (just like in a select, when you see the content of an option, not its value)

[Qouagga]

I restore the file

[garak]

Still, you need to solve the question about "url_get" option

[Qouagga]

I add this option url_get. And I add a suscriber to use url_get only on edit form.

[garak]

Can you please explain the need for a listener? Anyway, your current implementation of the listener cannot be accepted, since it's based on an arbitrary getId method.

[Qouagga]

Sorry for the delay. Actually, for each use of autocomplete, we have 2 request (one to search the list and another to search the name of the id put in the form noFakeInput). With the listener, we have one request to search the list and put in the noFakeInput. And a second request only if the form edit an entity. I don't understand, Doctrine create this getter method, getId. If this is an arbitrary method, where can I found the standard method (I don't found) ?

[garak]

I don't understand, Doctrine create this getter method, getId. If this is an arbitrary method, where can I found the standard method (I don't found) ?

Doctrine doesn't make any assumption on your entity: it will generate a getId() method only if you have an $id property. We can't assume that all users will have such property, nor that they will use Doctrine generation to generate such a method. There's no standard.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.

[stale[bot]]

This issue is closed because was marked as stale and had no activity. Thank you for your contributions.