support for GenericIPAddressField, fix manifest file

[machalekj]

Hi,
I needed to add support for Django >=1.4 GenericIPAddressField. I wrote it so it won't break support for older versions of Django. I also fixed bad format of manifest file - setup.py sdist wasn't working correctly with previous version.

[machalekj]

Hi, thanks for your immediate merge. Surely your general approach is better and sustainable than hard coding fields.

[tiliv]

Yeah, this actually touches another request #49, that we support third party fields that we basically have no control over. Your proposed change made it clear what would have to happen for both this ticket and that one.

Thanks for the contribution! :)

[ghost]

Thanks for that. I'm trying to figure out how to use this though. It is my understanding that I need to extend the FIELD_TYPES dict but I'm not sure how to pass it back to the view.

Can you help ?

[tiliv]

A note for this scenario is that the view right now has to assume that Field classes out there can be boiled down to one of the core Django types, so you would extend the FIELD_TYPES category according to how you want the new field to be treated. Whatever type you choose, the field will need to be capable of responding to the ORM query language for that field type.

For example, if you were to write a MyField class, you may implement special query language for it, such as MyObject.objects.filter(myfieldinstance__customquery=None), but DatatableView needs to reduce the field down to something simpler from the Django core, like a CharField. If MyField can respond to the standard text queries (icontains, startswith, all that stuff), then you could add this field to FIELD_TYPES["text"].

The view will inspect FIELD_TYPES for it's core list of known Django types, so putting your field in one of those categories automatically puts it into play.

You would be unable to add it to FIELD_TYPES["date"] if it fails to respond to the queries like myfield__year=2014. If you did this, the table would attempt to allow such a query as part of a search, and right away it would blow up.

Supporting non-standard field queries (e.g., the __customquery part of the above example) is something I want to do for the first full 1.0 release, but is not currently possible without unholy copy-pasting of the huge method.

I apologize for my long response time. Big things keeping me busy elsewhere, and I've been plotting the 1.0 goals and designs after using this code in production settings for the last couple of years.