This posts announces the release of django-autocomplete-light 3.1.2:

• #634: Select2 Upgrade
• #628: Do not rely on ids to fix container text
• #631: Initializing GFKs with values from forms
• #623: Fix setup.py extras by @ticosax
• #610: Cancel out Django’s style on lists

Enjoy B)

Currently, django-autocomplete-light v2 provides enhancement to default form field generation for model fields, depending on the registered autocompletes, as shown in the tutorial.

For v3, we don’t want this feature inside DAL anymore because it has really nothing to do with autocomplete. Instead, I’m trying to contribute a generic way to do that. It would not benefit only django-autocomplete-light anymore, but all Django apps. You could get enhanced default form fields for model fields just by installing and configuring apps in your project.

This post clarifies the status of django-autocomplete-light and strategy for v3.

Version 2

No further effort will be made to support new versions of Django in v2. However, it supports the current LTS Django 1.8 and future-release Django 1.10, so we’ve got plenty of time to re-do v2’s best features in v3 (in a better way) and most importantly you’ve got plenty of time to upgrade (until 2018).

Version 3

It’s a ground-up rewrite and it’s not backward compatible - hence the 2 years upgrade plan.

django-responsediff 0.3.0 has been released !

It now also checks the status_code, and has a cute mixin:

    from responsediff.test import ResponseDiffTestMixin

    class MixinTest(ResponseDiffTestMixin, test.TestCase):
        def test_admin(self):
            self.assertResponseDiffEmpty(test.Client().get('/admin/'))

The above will fail on the first time with FixtureCreated to indicate that it has written responsediff/tests/response_fixtures/MixinTest.test_admin/{content,status_code}.

This file is meant to be added to version control. So next time this will run, it will check that response.status_code and response.content is the same, in future version, or in other configurations (ie. py35, py27, pypy, etc …).

Anybody tried the Visual Python profiler ?

Check out this nice django admin theme: django-jets.

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.