I have a django view, and this view returns a table which is populated asynchronously with an ajax call.

From the design point of view, which one should I follow:

  1. the django view, called via ajax, returns the content of the table as a json response, containing html markups for each cell. The javascript callback handler takes the contents and slaps them untouched into the table cells.
  2. the django view, called via ajax, returns pure data about what should go into the table, again as a json response. The async javascript callback takes the data, formats them with proper markup, and puts it into the table.

In other words, who should have the responsibility for markup formatting of the cell contents? the view or the javascript ?

I would be tempted to say the first, since the view already returns marked up content. If it returns a json containing marked-up content, there's not much difference.

I would like to hear your point of view.

No correct solution


If you're populating the whole table, you can put your table in its own template and return the table's html via ajax/json.

You'll need to edit the original template to include the table template:

 {% include "myapp/_table.html" %}

And in the view, return the rendered template as a json variable, which your javascript will substitute in:

 return { 'table': render_to_string("myapp/_table.html", context) }

This approach is good where you always want to update the entire table, and the rendering of the table doesn't require the full context. I'm not sure what the performance is like, but it is a clean way of updating part of the page, because you only define your table once.

It depends (as so often).

If the data is requested only here and now, it would be easier and less error prone to just let it render on server-side with the same set of templates that already rendered the standard view.

If you could think of use cases however, where the data would be needed in other places (like auto-complete fields), it would be better to let JavaScript do the job and create a clean, reusable JSON export.

These options add to all the other answers, and finally it's up to you to decide.

In a MVP system such as Django, the View decides what data should be shown, and the Presenter decides how it should be shown. Therefore the JavaScript should do the bulk of the formatting unless it proves intractably difficult to do so.

It is a good to practice Unabstrusive javascript, also called by some people as Hijax

So, you first have a standard page, that presents the table along with the rest of the page, with table in a particular django-template block.

Once you have this, you can include the extends part of the django template within an "if not ajax", so you only get the required table part in the ajax response which you can load in the client to the required div.

It is un-necessary and redundant to maintain the markup twice once at the server and once at the client, in javascript.

hence, I'd prefer the first option, of server redering, and client only loading the rendered html.

I've come across this several times before, and I generally opt for the latter, where the view returns pure JSON.

However, the approach you choose should definitely depend on several factors, one of which is targeted devices (and their CPU/network constraints). Pure JSON will generally result in smaller payloads and so may be optimal for mobile devices.

It may also make sense to expose both HTML and JSON versions of your content. This is especially helpful if you're looking to create a very lightweight API at some point for your site.

Finally, you can use a library such as John Resig's micro-templating or Closure Templates to simplify client-side HTML generation.

I would go with first choice, sine it presents more pros for user: page loads instantly (no wait for async call), no JS required (e.g. for mobile device)

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top