Qui devrait formater mes données pour l'affichage?

Question

J'ai vue django, et ce point de vue retourne une table qui est peuplé de manière asynchrone avec un appel ajax.

Du point de vue de la conception, lequel dois-je suivre:

1. la vue django, appelé via Ajax, renvoie le contenu de la table en tant que réponse json, contenant des annotations html pour chaque cellule. Le gestionnaire de rappel javascript prend le contenu et les gifles intacte dans les cellules du tableau.
2. la vue django, appelé via ajax, renvoie des données pures sur ce qui devrait aller dans la table, encore une fois comme une réponse JSON. Le rappel async javascript prend les données, les formats avec un balisage approprié, et le met dans la table.

En d'autres termes, qui devraient avoir la responsabilité de la mise en forme de balisage du contenu des cellules? la vue ou le javascript?

Je serais tenté de dire que la première, car la vue retourne déjà contenu balisé. Si elle retourne un JSON contenant un contenu balisé, il n'y a pas beaucoup de différence.

Je voudrais entendre votre point de vue.

Answer 1

Si vous peuplant toute la table, vous pouvez mettre votre table dans son propre modèle et retourner le code HTML de la table via ajax / JSON.

Vous devez modifier le modèle d'origine pour inclure le modèle de table:

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

Et dans la vue, renvoyer le modèle rendu comme une variable JSON, que votre javascript substituera à:

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

Cette approche est bien où vous voulez toujours mettre à jour toute la table, et le rendu de la table ne nécessite pas tout le contexte. Je ne suis pas sûr de ce que la performance est comme, mais il est une manière propre de mettre à jour une partie de la page, parce que vous ne définissez que votre table une fois.

Answer 2

Cela dépend (comme souvent).

Si les données sont demandées seulement ici et maintenant, il serait plus facile et moins sujette aux erreurs à juste le laisser rendre sur le côté serveur avec le même ensemble de modèles qui ont déjà rendu la vue standard.

Si vous pouviez penser à des cas d'utilisation cependant, où les données seraient nécessaires dans d'autres endroits (comme les champs auto-complet), il serait préférable de laisser JavaScript faire le travail et créer une exportation JSON propre, réutilisable.

Ces options ajoutent à toutes les autres réponses, et enfin il est à vous de décider.

Answer 3

Dans un système MVP tels que Django, la vue décide quelles données doit être affiché et le présentateur décide comment il doit être démontré. Par conséquent, le JavaScript doit faire la majeure partie de la mise en forme à moins qu'il ne prouve irréductiblement difficile de le faire.

Answer 4

Il est bon de pratiquer le javascript Unabstrusive, aussi appelé par certains comme Hijax

Alors, il faut d'abord une page standard, qui présente la table ainsi que le reste de la page, avec une table dans un bloc particulier-template django.

Une fois que vous avez, vous pouvez inclure extends partie du modèle de django dans un obtenez « sinon ajax », vous seule la partie de la table nécessaire dans la réponse ajax que vous pouvez charger dans le client à la div nécessaire.

Il est non nécessaire et redondant pour maintenir le balisage une fois deux fois sur le serveur et une fois au client, en javascript.

donc, je préfère la première option, du serveur redering, et le client ne chargeant le code html rendu.

Answer 5

Je suis venu à travers plusieurs fois avant, et j'opte généralement pour ce dernier, d'où la vue retourne JSON pur.

Cependant, l'approche que vous choisissez doit certainement dépendre de plusieurs facteurs, dont l'un est des dispositifs ciblés (et leurs contraintes CPU / réseau). JSON pur se traduira généralement par des charges utiles plus petites et ainsi peut être optimale pour les appareils mobiles.

Il peut également judicieux d'exposer les deux versions HTML et JSON de votre contenu. Ceci est particulièrement utile si vous cherchez à créer une API très léger à un moment donné pour votre site.

Enfin, vous pouvez utiliser une bibliothèque tels que John Resig micro-templating ou fermeture Modèles pour simplifier la génération de HTML côté client.

Answer 6

Je voudrais aller avec le premier choix, sinus il présente plus d'avantages pour l'utilisateur: chargement de la page instantanément (pas d'attente pour les appels async), pas de JS requis (par exemple pour appareil mobile)