After 4 years of supporting django-autocomplete-light, I’m beginning to figure what users expect and the common mistakes, like registering the wrong model for autocomplete, or having troubbles figuring how to link suggestions with other form fields, or create choices on the fly, or with the magic modelform.

So at first, I really tried to find other autocompletion apps for with DAL could be just an extension. It turned out that with they had too much security issues, known security vulnerabilities which aren’t going to be fixed (which I don’t dare to post here). As I have strong feelings about security, I decided to take another road, and took a 2-week code sprint working at night to make version 3.

Markus Holtermann has published a tutorial for setting up syntax highlighting for Django’s SQL query logging. I didn’t try it but it looks pretty cool, maybe that’s something we could add to django-dbdiff somehow. Anyway, check it out !

This release fixes an important usability but on the manychoice fields, and introduces a minor backward compatibility break:

• #563 Don’t disable multiplechoicewidgets if select is [multiple], bd9ca0085
• Don’t import anything in init anymore if on django 1.9
• test_project fixes, for the above.

Disabled field bug

Thanks George Tantiras for reporting the bug ! Note that only paliative solutions have been taken for v2:

• repaired the demo website, should make it easier to spot bugs,
• bug fix in the JS.

As for v3, it is designed to support any number of autocomplete scripts, and the first proposed implementation is with select2, so chances that this kind of bug happen are greatly reduced.

As stated in the “Database state assertion” article: I’m pretty lazy when it comes to writing tests for existing code, however, I’m even lazier when it comes to repetitive manual testing action.

When my user tests my website, they browse it and check that everything is rendered fine. In the same fashion, django-responsediff eases doing the high-level assertions of page HTML rendering.

Consider this example:

    class TestYourView(TestCase):
        def test_your_page(self):
            result = test.Client().get(your_url)

            # Factory to create a Response for this test
            expected = Response.for_test(self)

            # Generate the fixture if necessary, otherwise GNU diff-it
            expected.assertNoDiff(result)

On the first run, this would create a directory in the directory containing TestYourView, named responsediff_fixtures, with a sub-directory TestYourView.test_your_page and a file content with response.content in there, if it does not already exist, and raise FixtureCreated to inform the user that no test has actually been run, and that the fixture has just been created.

• #555 Django 1.4, 1.5 and 1.6 deprecation
• #497 Enable registration by model-name by @luzfcb
• #536 #551 Support proxy models b y @onrik
• #553 improved jQuery integration by @blueyed
• #516 Corrected french transation by @apinsard
• #541 Use error_messages on FieldBase to allow overrides by @dsanders11
• #505 Ordering alias clash fix by @sandroden
• #515 Polish translation update by @mpasternak
• #543 ModelChoiceField requires the queryset argument
• #494 ModelChoiceField Watch changes to ‘queryset’ by @jonashaag
• #514 Fixed deprecation warning on Django 1.8 by @spookylukey
• #498 #548 improved i18n support
• #547 prevents loading genericm2m if not in INSTALLED_APPS
• JAL#18 Fix: Get value.length while value is null by @hongquan
• JAL#19 Clarify license by @stevellis, all MIT
• JAL#17 Disable the widget input when it is not in use @dsanders11
• JAL#15 Support openning results in new tab @thebao
• JAL#14 Don’t autohilight first choice by default @pandabuilder
• JAL#13 Add option for box aligning with right edge of input @dsanders11

#536 At this point, proxy model support is untested, this is because I intend to refactor the test suite and documentation during the 2.3.x serie.

I’m pretty lazy when it comes to writing tests for existing code, however, I’m even lazier when it comes to repetitive manual testing action, we’ve got so much patches to review and test against so many versions of Python and Django, we need testing to be automated.

This article presents a new Django app for testing the database. Java has DBunit and so does PHP, and django now has django-dbdiff.

Database testing

A nice way to test a data import script is to create a source data fixture with a subset of data, ie. with only 10 cities instead of 28K or only 3 european parliament representatives instead of 3600, feed the import function with that and then compare the database state with a django fixture. This looks like what I was used to do:

django-cities-light 3.2.0 was released, supporting Django 1.7 to 1.9 now, even though older versions should still work, they aren’t tested anymore.

• #105: Drop LazyProgressBar, patch was accepted upstream by Max Arnold,
• #104: Better feature code filtering by Max Arnold and Michael Gulev,
• #100, #96: The mystery about migrations appearing in some environments but not others has been solved: it was due to the presence of b'' in migration files. A new test was added to fail if django wants to create new migrations in any environment.
• Phone number was required to create a country, it’s not anymore.
• Support Django 1.7 to 1.9, thanks Georgy Kutsurua for helping,
• Support for 1.7 will drop when 1.10 is released, unless someone contributes compatibility in cities_light options declaration,
• Bugfix in import: some search names would not be generated in some cases due to unpredictability of the iteration order on translation_data.items()
• Test with django-dbdiff are much faster than importing the whole data
• Tox for testing, coverage

Starting 2.3.0, django-session-security supports Django 1.7 to Django 1.10 with tox.

In 2.3.1, Andrei Coman added redirectTo parameter and tests were stabilized using django-sbo-selenium and tox.

Since Django 1.9a1 was released, many users are going to upgrade their project and wonder why django-autocomplete-light won’t load anymore. Probably, some users are going to google ImportError or even django.core.exceptions.AppRegistryNotReady: Apps aren't loaded yet about autocomplete_light and Django 1.9. This post documents the situation and provides a solution.

Do:

    find test/ -name foo -exec sed -i 's/import autocomplete_light/from autocomplete_light import shortcuts as autocomplete_light/' '{}' \;

I don’t remember why exactly since we’ve baked Django 1.9 support in April 2015 (victory !!!), but IIRC due to app-loading refactor we can’t have anything in __init__.py for installed apps just for convenience anymore (ie. model imports). To maintain as much backward compatibility as possible, we still load what we can there, but please use autocomplete_light.shortcuts instead.

Getting started with SaltStack usually means piling up a bunch of YAML code templated with Jinja in a source code repository because that’s the way to go from the documentation’s point of view. With significant whitespace, YAML enables even non-developers to define data structures in non verbose way. Jinja2 is a templating engine which enables a non-developer to make YAML files dynamic, typically depending on variables. However, Jinja2 hasn’t significant whitespace and this can decrease readability of YAML templates. And since YAML and Jinja2 are two different languages in the same file, there is no readable way to ident code. Not to mention that Jinja2, as a template language rather than a programing language, has a pretty limited subset of operators.