0.9.0-beta.4

Refinements since 0.9.0-beta.3

Sphinx documentation and Travis CI are now public:

• http://django-datatable-view.readthedocs.org/en/latest/
• https://travis-ci.org/pivotal-energy-solutions/django-datatable-view

Fixes:

• Several issues with LegacyConfiguration innards (sorting, some column names raising unexpected exceptions before the intended exception could be raised)
• Imports for some versions of Django
• Removed forced sortable=False kwarg when no sources are given (this was causing issues with columns that are expected to be sortable based on processor output)
• Fixed hook lookup for per-column searches
• Changed when internal configuration takes place on a Datatable

0.9.0-beta.3

Refinements since 0.9.0-beta.2

We've added Sphinx documentation that we intend to have pushed to readthedocs.org, which will serve as the new primary documentation source. A new live demo site for 0.9 will be launched soon (we want to keep 0.8 around because of this transitionary period for new syntax), and it will continue to play an important role in providing short and sweet examples, but it's not always a perfect substitute for the actual module documentation. The documentation is stored at django-datatable-view/docs/, alongside the datatableview python module.

• Fixed sorting of non-db columns
• Addition of column getter for extra kwargs to be sent to its processor function
• Require column kwarg sortable=False when no sources are present
• Internal method renames
• helpers.through_filter renamed to helpers.make_processor

0.9.0-beta.2

New features

It turns out I forgot to reintroduce some old functionality in the new modern column format code, but it's back!

• Support for model fields that use choices. Specifically, we enable the user to search for the (case-insensitive) label of the various choices and the column will flip the search term to the right thing. Fixed a bug in 0.8 choices support that made some assumptions that the choice db value was a string (using iexact too aggressively).
• strptime date formatting will attempt to parse individual numbers and strings for matches that satisfy format symbols, such as %y (two digit year) and %M (month names).

Fixes

• Fixed a bug with legacy configuration where a sources list defined as a list instead of a tuple would cause dictionary key issues. [43ade82]
• Fixed an issue with LegacyConfigurationDatatableView skipping the implicit processor discovery phase. This will be removed in 1.0, but for 0.9 we will continue supporting implicit callbacks when the legacy view is in use. [88a0318]
• Fixed a bug with columns declaring multiple sources that each targeted a value across an m2m relationship, where sources after the first would attempt to inspect the ORM path starting on the model where the first source left off during its own lookup. [4f0af04]
• Fixed an issue with sending multiple column sources directly to the link_to_model helper, where the generated link text was a repr() of the source values list, instead of the default ' '-joined list of those values. [a27b6eb]
• Changed choices label matching to support partial matches.
• Changed choices label matching to allow multiple matches (since partial matching is now also allowed). Previously there was a nuance that if two choices had the same label for whatever reason, it was undefined behavior which one would be selected to represent the database value in the converted search query.

0.9.0-beta.1

This is a transition release to get people to 1.0, which brings a lot of syntax changes for table declaration on the python view, adopting a strategy that looks a lot like Django's forms framework,
or django-rest-framework's serializers.

0.9 will continue to offer backwards-compatible datatable declaration with the help of a LegacyConfigurationDatatableView as a baseclass. DatatableView will presume that the modern configuration style is being used and will raise errors accordingly.

wheel installation is also possible now.

The live demo site at http://django-datatable-view.appspot.com will continue to operate WITHOUT this beta release, so experimenting with interactive documentation will require that you run the included example project, which includes a 0.9 migration guide. See the main README.md for quick instructions to get the example project running locally.

0.8.3

Important future note

This is the last planned release for the 0.8 series! 0.9 and 1.0 will arrive simultaneously sometime during the next couple of weeks, and the entire declaration process for datatableview options has been modernized.

0.9 will include all of the existing "legacy" configuration code from the 0.8 releases, powered by brand new internals. 0.9 will be a no-fuss update, but if you plan to jump up to 1.0, you will need to following the forthcoming migration guide to get away from these "legacy" delcaration syntaxes.

Release notes

Added an optional setting named DATATABLEVIEW_MINIMUM_DATE to try and combat an issue with some databases not liking datetime.MINYEAR as a valid number for the year of a date column.

Added a fix for some versions of Django misunderstanding a GenericForeignKey when inspecting object relationships for column data.

0.8.2

Important future note

This is the last planned release for the 0.8 series! 0.9 and 1.0 will arrive simultaneously sometime during the next couple of weeks, and the entire declaration process for datatableview options has been modernized.

0.9 will include all of the existing "legacy" configuration code from the 0.8 releases, powered by brand new internals. 0.9 will be a no-fuss update, but if you plan to jump up to 1.0, you will need to following the forthcoming migration guide to get away from these "legacy" delcaration syntaxes.

Release notes

This release fixes a number of internal issues for newer versions of Django, most notably the tests! With the introduction of Django's AppConfig system, the hack we've been using (keeping a testing-only app with testing-only models nested inside of the main datatableview app) was broken by a change concerning which app label Django thought the model belonged to. The tests themselves were doing okay, had they not been failing during the fixture loading process.

@PamelaM has added initial support for including Travis testing into the repository, which is long overdue for a repository that has been gaining popularity over the last couple of years. I will commit to keeping up with it since, as they sometimes say, an untested app is considered broken by default.

Another Django 1.7 bug with related model fields was fixed, also thanks to @PamelaM.

Other miscellaneous changes:

• The datatableview.utils.FIELD_TYPES dictionary is now a defaultdict(list) (@davidfischer-ch)
• PEP-8 spacing changes (@davidfischer-ch)
• Added a queryset.distinct() to get around some funny Q() math (@@davidfischer-ch)
• Added/fixed various utf-8 encoding declarations on source files (@davidfischer-ch)
• Preemptive fixes for Django 1.8 and 1.9 import locations (@greenbender)
• Corrected string coercion when ugettext strings were being used as the starting point for looking up a method name (@akx)

0.8.1

This release fixes a Django >=1.7 compatibility bug where ORM query lookups would traverse a m2m relationship and incorrectly discover the manager to be a callable value function.

A small translation fix was provided, a wasteful count() query removed, NullBooleanField is now added to the 'boolean' FIELD_TYPES, and we fixed a documentation typo that referred users to the wrong javascript callback name.

0.8.0

This release modifies the way model fields are detected for ORM queries when submitting a search. Previously, the approach was primarily hard-coded to support only the core Django fields that served as base classes for all others, but this approach failed to provide any value for third-party fields that were built from scratch.

As of this release, datatableview.utils contains a dictionary FIELD_TYPES that contains keys for the major field categories, and maps each one to a list of fields that can be treated identically in ORM query terms. This dictionary can be extended by importing it and appending new fields to a category.

The default registration dictionary looks like this:

FIELD_TYPES = {
    'text': [models.CharField, models.TextField, models.FileField, models.GenericIPAddressField],
    'date': [models.DateField],
    'boolean': [models.BooleanField],
    'integer': [models.IntegerField, models.AutoField],
    'float': [models.FloatField, models.DecimalField],

    # No direct search ORM queries make sense against these field types
    'ignored': [models.ForeignKey],
}

If a field type used in a table but isn't found in any of these categories, the old familiar exception will be raised stating that it is an unhandled field type. The correct solution is to import this registry and append the field class:

from datatableview.utils import FIELD_TYPES
from netfields.fields import InetAddressField
FIELD_TYPES['text'].append(InetAddressField)

In the future, looking towards the full 1.0 release, we would like to offer a more sophistocated field type registration that allows the new field to also declare what unique ORM extensions it offers, in the way that a CharField offers __icontains, or InetAddressField offers __net_contains, etc. Until 1.0, we will be limited to offering this simple registration that limits the field categories to those already listed.

0.7.3

This release fixes an exception that is raised when using Django 1.7 release candidate, involving the removal of the deprecated StrAndUnicode utility base class.

0.7.2

This release fixes an issue involving verbose_name values wrapped in a proxy function used by
Django to defer instantiation of an underlying object. These proxy values could not go through the re framework without raising errors about "expecting a string or buffer".