tags:

views:

95

answers:

6

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.

+1  A: 

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.

Ignacio Vazquez-Abrams
If a template is still being used to format the returned AJAX data on the server side (in fact, could be the same template used to originally generate the table, as some answers have suggested), then ISTM the presentation logic is still in the right place even if HTML is returned. Doing the formatting in JS in that case is just harder, more error prone, slower, and less DRY.
Carl Meyer
+1  A: 

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.

Lakshman Prasad
+3  A: 

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.

Will Hardy
that's not exactly possible. I am updating the table progressively, to be honest.
Stefano Borini
Well I guess it depends on how much markup you're talking about. I prefer to have the data formatted before it is sent to the user, but it really depends on what sort of formatting you're doing. I think this general question can't and maybe shouldn't be answered with a single answer.My approach in my `django-adjax` app is to have the data formatted in the model. Either the value is provided as is, or a method is referenced, where the proper value is supplied. This has been enough for me, but I haven't had to deal with your specific requirements :-)
Will Hardy
+1  A: 

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.

Roman Nurik
+2  A: 

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.

Boldewyn
A: 

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)

Dmitry Shevchenko