Support JQuery-UI widget

[mpasternak]

Hi,

I have a use-case, where a jquery-ui autocomplete widget would come in very handy.

Also, djangopackages.org says, that we don't support JQuery-UI widget, but why couldn't we?

At this moment, I share with you a pretty basic JSONP-producing class AND a HTML file with example use of jquery-ui widget. As jquery-ui widget seems to be pretty extensible now and it supports both multiple values http://jqueryui.com/autocomplete/#multiple-remote and scrollable results http://jqueryui.com/autocomplete/#maxheight and many more stuff, perhaps at some point in the future it would be cool to add more jquery-ui autocomplete widget features.

But for now, you get a very basic support with some simple code, that I really copy-pasted from stackoverflow.com , with some minor edits. Because, why shouldn't we support jquery-ui? I don't see why :-)

[jpic]

Good job, then we could render the widget with data-bootstrap="jqueryui" to get jqueryui to fire instead of widget.js.

Note that I was planning in supporting various scripts in v2. Actually I would already be there if I was not wondering, should I:

• make a clear difference between the concepts of Autocomplete "Frontend" (rendering functions) and Autocomplete "Backend" (business logic) ? that would 0. break BC and 1. Force a stricter AutocompleteInterface (since some functions like choice_value are used by both the frontend and the backend) but 2. Make it much easier to understand and use for developers who don't have a clear idea of how mixins work.
• just leave it as is and start adding: AutocompleteHaystack (with haystack for backend), AutocompleteJqueryui (with jQueryUi for frontend), AutocompleteSelect2, AutocompleteJqChoice, AutocompleteTypeahead ...

Basically, I'm wondering, should v2 try to respect BC as much as possible, or should I make v2 another project, or should I not hesitate to break BC and make the best v2 and support v1 for like 2 years (not really a problem for me).

I wish I could clarify the concept of an autocomplete being:

• a form field for validation,
• a widget for rendering,
• a backend for business logic,
• a frontend for rendering the list and choices,
• a bootstrap script.

But I might completely kill BC doing that ...

Anyway, you're probably in a hurry so I'll help you finishing this right away.

BTW, did you see that v2 allows a much more DRY configuration ? Just register an autocomplete and use autocomplete_light.ModelForm and it will use registered autocompletes by default (even for generic fk and generic m2m !), check it out: https://github.com/yourlabs/django-autocomplete-light/blob/v2/autocomplete_light/tests/apps/basic/forms.py

[mpasternak]

Hi,

I haven't seen v2.

What's important in django-autocomplete-light for me: the drop-in replacement for admin and forms is pretty cool, turnkey solution. Another good thing: autocomplete registries, where (as I have shown in my branch) I can get new functionality (JSONP for JQuery-UI control) with very minimal changes.

What I currently have trouble with: the widget. There are some funky bugs with grappelli inline formset and current widget implementation in my project. I have not yet tested them, as I am working on another part, and that another part uses https://github.com/mpasternak/django-multiseek with Zurb Foundation 4 with django-autocomplete-light and because of the way django-autocomplete-light widget is initialized and the way foundation4 custom forms work, I will rather use JQuery-UI widget for that project. Which made me think, how about using JQuery-UI widget for admin too, would that work, perhaps would that be less buggy for me? I'll see if I go in this direction.

For now, I'd really love something like mpasternak@4d5331a in the main branch, as this will allow me to easily cooperate with JQuery-UI widget.

What I would do with the library at this moment? I don't know about your use-cases, looking at apps like cities_light and multiple elements in autocompletes I think they are pretty different, than my use-cases which are much simpler. But, nevertheless: my gut feeling is that I would drop widget.js and use some 3rd-party widget library OR various 3rd party widget libraries, because I don't think that we will be able to support a properly working, styleable, mobile-enabled, and so on, so on ... javascript widget, just because 3rd-party libraries simply do it better. So I'd focus on backend (making it pluggable for many different javascript widgets) AND automatic Django forms and admin stuff (with configurable kind of widget). Just my $.25, and please have in mind, that I don't have knowledge neither about your use cases nor about what's possible with django-autocomplete-light.

Thank you!

[jpic]

Thanks for your feedback.

The problem with v1 which relies on just a widget, is that we have to do validation in widget.render() which causes performance problems in some cases (see #168). So the validation process must happen in the form field validate() method.

But fear not, thanks to the tests, v2 doesn't break apps built with v1 (there will be minor BC breaks which have been announced for some time). The v1 API will still work but it won't be as awesome as the v2 API (which uses form fields for validation and has a ModelForm metaclass which is able to setup all autocompletes without you having to do a single line of code).

v2 will have a solution for #118 which will hopefully lead to a supported way to rely on custom scripts. I myself would like to have typeahead or jqchoice or select2 in some specific cases (but not jqueryui personally I find it way too heavy, but I don't say we shouldn't support it).
We could make a minimal widget.js which uses events (javascript signals) to connect with external widget scripts - because we still want to support add-another and all.

I can merge AutocompleteJSONP if you really need it now, but it should be in autocomplete_light.autocomplete.jsonp. Else I'll merge it later this week probably after I have all the v1 tests working again on python3. Let me know ;)

Thanks again for your feedback, really appreciated, it helped saving the v1 Autocomplete API !