Integration/Cooperation with django-tables2

[winhamwr]

I wonder if a project that basically wraps https://github.com/bradleyayers/django-tables2 would cut down the scope on what needs to happen here. It seems like the base problem of defining a table, columns, data source, etc. is all within the scope of django-tables2. I've been using a forked version of that project with great success, and it seems like wrapping their table object to provide ways of handling datatables' requirements might be a good fit.

Are you familiar with this project?

[christhekeele]

Actually, yes, I made a handful of commits to it a month ago. Those commits were geared towards making the paginator variable more accessible, to allow me to insert an AJAX paginator in its stead. While I succeeded in making the paginator overridable, I couldn't get the ajax to take.

The issue lies in the model-form style of bound table, column, and row instances. That handy and powerful {% render_table table_object %} also comes with a few catches.

• It means you can't do in-template styling or structuring of table elements, you must modify a separate template, feed it into the table object, etc. As I rarely touch the templates, that means my front end guy has to go into the tables2 templates and figure out how to change it. I'd rather have more granular and customizable hooks to different datatable elements; like the search bar, pagination links, and filters; inserted at my front-end guy's discretion around the standard {% for object in object_list %} loop.
• It means if you're moving an app over from using {% for object in object_list %} querysets, you have to adapt to the new tables.py style and syntax. It's not a huge learning curve or anything, as table2 is very intuitively built and well documented. This project isn't going to be the most robust solution, but I'd like it to be a very accessible one.
• It means that django-tables2 loads all elements of the table on page load. I couldn't find a way to ajaxify it because it needs the context of the entire dataset to create the bound rows and columns. With a heavy dataset, that's non-negotiable.

I'm interested in hearing more about the fork you're using. I started my search for a good django datatables.net-style app with django-tables2. After spending a bit of time in the code base I decided to move away from it for the reasons above.

tldr; Tables2's bound model-form style tables are great, but provide limitations that a queryset style {% for object in object_list %} can overcome.

[winhamwr]

Hi Christopher,

I completely agree with your assessment of the trade-offs in the queryset style versus the way django-tables2 does the display. I hadn't actually dove too far in to the code there, as we've been using a fork of django-tables that diverged before django-tables2 started: https://github.com/PolicyStat/django-tables/tree/overload_columns

For our fork, we went with more of a template-controlled queryset style of things. The basic idea is that you have a certain model that you want to display in tables, but you probably have a half-dozen different variations on how you'd like to display that based on what you're trying to accomplish. Instead of defining 6 different table objects in python, each Model generally has exactly one table object, but defines lots of different variations on how a column is displayed (while still maintaining automatic sorting/searching on the underlying column).

For example, I might have a "name" field on a document, but there might be 2 different ways of displaying that. One that is just the text and one that is the text but links to a page for editing the document. You can then define a name column and a name_edit_link column and use render_name_edit_link to define the edit link's behavior.

Then in your template, you have a columns object on your table that lets you access header information. You also have a list of row objects, that let you choose which method to use for rendering a particular column ( eg. {{ row.name }} vs {{ row.name_edit_link }}). I just put up a gist with our most complicated table: https://gist.github.com/2719564

AJAXifying a lot of our search results tables is something that will happen soon(tm), so when I start that project, I'm going to take a much closer look at how I might be able to integrate what you're doing here with our data tables. It would be pretty exciting to be able to define your entire data model display relationship in one tables.py file, use a template to layout the particulars of one display and then get free AJAX-y pagination, search, and filtering because your javascript knows how to talk to the server and process the JSON.

Of course, if I need to use our fork to make it work, I'll need to spend some time making the documentation not suck.

Thanks for open-sourcing this project. Hopefully you'll be seeing some pull requests from me at some point :)

-Wes