2009-10-02 9 views
0

Comment concevoir une application Django/Javascript pour fournir des réponses Ajax conditionnelles aux requêtes HTTP conventionnelles?Est-ce que Django/Javascript peut gérer les réponses "Ajax" conditionnelles aux requêtes HTTP POST?

Sur le serveur, j'ai un objet Form personnalisé. Lorsque le navigateur envoie les données du formulaire, le serveur vérifie les données soumises par rapport aux données et règles existantes (par exemple, si le formulaire ajoute une entité à une base de données, cette entité existe-t-elle déjà dans la base de données?). Si les données sont transmises, le serveur enregistre, génère un numéro d'identification et l'ajoute aux données du formulaire, puis transmet le formulaire et les données au navigateur.

if request.method == 'POST': 
    formClass = form_code.getCustomForm() 
    thisForm = formClass(data=request.POST) 
    if thisForm.isvalid(): 
     saveCheck = thisForm.saveData() 
     t = loader.get_template("CustomerForm.html") 
     c = Context({ 'expectedFormObj': thisForm }) 

(Notez que ma logique personnalisée vérification est en SAVEDATA() et est séparé de la validation HTML fait par isValid().)

Jusqu'à présent, Django standard (je l'espère). Mais si les données ne passent pas, je veux envoyer un message au navigateur. Je suppose que saveData() pourrait mettre le message dans un attribut du formulaire, et le gabarit pourrait vérifier cet attribut, intégrer ses données en tant que variable javascript et inclure une fonction javascript pour afficher le message. Mais passer tout ce qui forme html, juste pour ajouter un message, semble inélégant (comme le fait le processus standard de soumission de formulaire Django, mais peu importe). Dans ce cas, j'aimerais simplement faire passer le message. Maintenant je suppose que je pourrais lier une fonction Javascript à l'événement onsubmit du formulaire html, et avoir ce problème XMLHttpRequest, et avoir le serveur répondre à cela basé sur la sortie de l'appel saveData(). Mais alors le navigateur a deux demandes au serveur en suspens (POST et XHR). Peut-être qu'un saveData() réussirait à réécrire toute la page et à effacer tout potentiel de conflit. Mais je devrais aussi demander au serveur de séquencer sa réponse au XHR pour suivre la réponse au POST, et comprendre comment communiquer le résultat de saveData à la réponse au XHR. Je suppose que c'est faisable, même sans la programmation de fil, je ne sais pas, mais il semble malpropre.

Je suppose que je pourrais utiliser javascript pour rendre la réponse du navigateur conditionnelle à quelque chose dans la réponse à la demande POST (soit réécrire la page entière, ou simplement afficher un message). Mais je soupçonne que les mains javascript de la page contrôlent le navigateur avec la demande POST, et que toute réponse au POST ne ferait que réécrire la page.

Alors, est-ce que je peux concevoir un processus pour renvoyer le formulaire entier seulement si saveData() fonctionne côté serveur, et un message qui est affiché sans réécrire le formulaire entier si saveData() ne fonctionne pas? Si c'est le cas, comment?

+1

Ceci est probablement trop long. – chernevik

Répondre

3

Bien que vous puissiez organiser votre point de vue d'examiner les données de demande de décider si la réponse Mettez les gestionnaires de requêtes AJAX dans une structure d'URL distincte, par exemple toutes vos vues html ordinaires ont des urls comme/foo/bar et un appel api correspondant pour la même information Étant donné que la plupart des vues examinent les données de la requête, puis effectuent un traitement, puis créent un dictionnaire Python et le transmettent au moteur de gabarit, vous pouvez factoriser les parties communes pour c'est un peu plus facile. les premières étapes pourraient être une sorte générique de fonction qui retourne juste le dictionnaire python, et ensuite les vraies réponses sont composées en enveloppant les fonctions de gestionnaire dans un moteur de rendu de modèle ou un encodeur json.Mon flux de travail habituel consiste à supposer initialement que le client n'a pas javascript, (ce qui est encore une hypothèse valide, de nombreux navigateurs mobiles n'ont pas de JS) et implémenter l'application en tant que gestionnaires statiques GET et POST. De là, je commence à chercher les endroits où mon application peut bénéficier d'un peu de script côté client. Par exemple, je vais généralement redessiner les formulaires à soumettre via des appels de type AJAX sans recharger une page. Ceux-ci n'enverront pas leurs demandes à la même vue d'URL/django que la version de formulaire html simple, puisque la réponse doit être un simple message de succès en texte brut ou fragment html.

De même, obtenir des données à partir du serveur est également repensé pour répondre avec un document JSoN concis à traiter dans la page sur le client. Ce serait également une vue URL/django séparée en tant que html simple correspondant pour cette ressource.

+0

Merci - comme je l'ai posté, l'ensemble semblait être une mauvaise idée. Deux questions. 1) Je ne suis qu'un oeuf, et ne groin pas "appel API". Cela renvoie-t-il ici à un appel par les fonctions Ajax? 2) Comme je comprends le deuxième paragraphe, le serveur renverrait tout le code HTML pour le formulaire, avec des bits supplémentaires le cas échéant. Oui? – chernevik

0

Pour votre information, ce n'est pas une réponse ... mais il peut vous aider à réfléchir à une autre façon

Voici le problème que je cours dans ... Google App Engine + jQuery Ajax = 405 Method Not Allowed.

Donc, fondamentalement, je reçois la chose à travailler en utilisant le code décrit, alors je ne peux pas faire la requête AJAX :(.

3

Lorsque vous traitez avec AJAX, j'utiliser ceci:

from django.utils import simplejson 
... 
status = simplejson.dumps({'status': "success"}) 
return HttpResponse(status, mimetype="application/json") 

Ensuite, AJAX (jQuery) peut faire ce qu'il veut en fonction de la valeur de retour de 'statut'.

Je ne sais pas exactement ce que vous voulez en ce qui concerne les formulaires. Si vous voulez une expérience de forme plus facile, et mieux, je suggère de vérifier uni-form. Pinax a une bonne mise en œuvre de ce dans leur application de vote.