In AgnoCompleteURl proxy, when building the final payload, add a mechanism in order to skip an item if needed.

When using an AgnocompleteModelMultipleField field, new values can be created via the create_new_values method https://github.com/novafloss/django-agnocomplete/blob/master/agnocomplete/fields.py#L184. To avoid any constraint issues (like IntegrityError) we need to use get_or_create by default but make it overridable if the final user needs to create multiple objects with the same values.

It really looked nice, but I'm puzzled... was it really useful?

I'd go for the MIT.

Hey,

some deprecation while using django-agnocomplete==0.4.0

#####/agnocomplete/__init__.py:11: RemovedInDjango19Warning: django.utils.importlib will be removed in Django 1.9.
  from django.utils.importlib import import_module

We'll try to integrate the selectize.js autocomplete in a automatically generated admin context.

Should be loaded from README.rst.
Maybe it's time to switch from this setup.py to setup.cfg, it'll make things a bit easier, probably.

• As a backend parameter, it has a minimum value, a max value and a default value.
• page_size as a client argument: page_size argument to override the default. Although this argument can't be over limits.

in order to ease the extraction of meta or extra data, expose a final_queryset property or method.

• remove sqlite database, doc builds from the release package
• add the "RTFD" build,
• add build/ sdists/ directories to the .gitignore

Django 2.0 and 2.1 support was dropped in 2019.
refs: https://endoflife.date/django

refs: https://endoflife.date/django

As far as I can say, its support has been dropped on April 1st, 2020
Two birds with one stone: it'll drop support for ye'old Python 2.7

https://harvesthq.github.io/chosen/

RemovedInDjango19Warning: `request.REQUEST` is deprecated, use `request.GET` or `request.POST` instead.
  query = self.request.REQUEST.get('q', "")

gotta choose if we stick to the GET queries or if we want to handle both GET and POST queries.

Warning, this version does not support Python 2 anymore...

since it's not using the Django 1.7+ app loading, it's incorrect. Spotted during #27, fixed in the related branch.

ref: https://endoflife.date/python

As far as I can say, its support ended on September 2020

At the moment, we're only able to have the first page of suggestions. Good enough for the 0.1 release.

Eventually, we may want to jump to the next page, using a page argument.

• I assume that nobody will ever want a "jump to the last page" feature. We hit the "next" page. If the resultset is empty, there won't be a jump to "next" button,
• I assume that nobody will ever want a "jump to page 'n'" feature.
• We definitely need to make it safe from a performance perspective, with a "don't use the offset" mechanism in mind (chunkator?)

So, how do we do that?

in order to enable the display label or returned object, add an item(current_item) method to the AgnocompleteChoices class.

Integrator should be able to provide a list of values to be proposed in the field values when the field is displayed. These are "non-selected" values, and ready-to-be-used without having to trigger an autocomplete query. Ex:

<select data-url="/somewhere/" data-query-size="3" name="friend_with">
   <option value="me">Me</option>
   <option value="everyone">Everyone</option>
</select>

Questions:

If the field has already a value:

• are these default values retrieved and sent to the client, along with the selected value(s)?
• if by default they're not sending these values, do we provide a custom flag to allow them to be sent anyway?

study the opportunity to simply have a "proxy" agnocomplete core object, one we could parametrize using a simple url argument. It would simply pass the q query to the target URL, retrieve its results (JSON) and re-build a "agnocomplete-compliant" resultset.

Idea:

• take a chance to allow context-related arguments to be added to the URL argument,
• the target URL argument could be a parameter: "query" or "search" instead of "q".

In the case of a multiple heritage UserContextFormMixin forces the other classes to not have a user argument in the constructor.

Should be more flexible.

When overriding AgnocompleteModel.item to customize item display, initial value for AgnocompleteField is still displayed using the model's default string conversion method. AgnocompleteModel.item should also be called on it.

Even if we don't use those internally yet :)

Following #60 ; low priority, but it'd be nice to show errors when they happen in the demo. To give an example on how to handle them. Add it to the docs, also.

needs introspection to eventually fix this. Possibly due to the utf8 special chars in the fixtures.

Let's discuss this:

• there are several pre-release branches, carrying the RC tags,
• some of these RC were not linearly stacked on each other, it may have happened that some commits that were on master were not on these RC (the error handling bit, for example),
• as a consequence, one could think we may delete these branches, but on the other hand, deleting these branches means "deleting the tags".
• on the other hand, these RCs were published on PyPI ; if somebody wants to browse the code, they can still download the tarball from PyPI.

At the moment, it's an "OR", shall we provide a parameter to tell it's an and search?

to avoid the "deprecation warning":

 RemovedInDjango110Warning: Support for string view arguments to url() is deprecated and will be removed in Django 1.10 (got demo.views.selectize_context_tag). Pass the callable instead.