web développement web "2.0" et structuration du code - Page 2

non ça c'est la 2 ; la 3 oblige à repartir des paramètres de la query string à chaque fois, et donc les valider, faire les select en base, etc.

je ne vois pas bien pourquoi il faut deux fonctions à chaque fois, alors

bah comment tu ferais, en Django ?

#up#
Je viens de me souvenir que je n'avais pas répondu à ça ^^

Si j'ai bien compris le problème, tu veux afficher une page, qui est composée de deux morceaux, le premier morceau nécessite un appel à ma_fonction_1(), le second demande un appel à ma_fonction_2().

Ensuite, tu veux pouvoir construire la page d'un seul bloc (on appelle alors une fonction ma_page_complete() qui appelle elle-même ma_fonction_1() et ma_fonction_2()), ou alors en AJAX, avec deux requêtes HTTP, qui appellent successivement ma_fonction_1() et ma_fonction_2().

Ce qui te gêne, c'est de faire la vérification des arguments dans ma_fonction_1() et ma_fonction_2() (ce qui ne sert à rien quand on utilise ma_page_complete()), ou de faire plein de if pour distinguer dans ma_fonction_1() et ma_fonction_2() si on est dans un appel AJAX ou non.

Ai-je bon ?

Avec Django, tu peux faire un middleware, qui va intercepter les requêtes HTTP et les réponses fournies. Pour les urls de type /ajax/functions, il s'occupe de vérifier les arguments, puis d'appeler la sous-fonction ma_fonction_1() ou ma_fonction_2(), et enfin de transformer le résultat en JSON. Pour les urls de type /static/functions (et donc l'appel à ma_page_complete()), il ne fait rien : ma_page_complete() est appelée normalement et elle s'occupe des vérifications. Du coup, zéro duplication de code, et zéro code inutile, tout se fait de façon transparente (mais il faut prévoir des arguments un peu normalisés pour que topic_id représente toujours un identifiant de topic afin de vérifier les arguments facilement).

heu j'avoue que je n'ai plus trop le problème en tête

J'étais parti exactement sur la solution que tu proposes, avec des URLs en /frame/xxx qui sont des bouts de page autonomes, et d'autres en /page/yyy pour afficher une "page" qui est un rassemblement de frames. Mais pour une raison qui ne me semble plus évidente du tout, ça ne suffisait pas, il faut que je retrouve la raison

(il me semble que c'était davantage un problème lié à django et ses templates très limités, qu'au fonctionnement théorique de cette organisation)

peut-être à cause du code de vérif à ajouter dans chaque fonction, même s'il n'était pas toujours utilisé ? Utilisais-tu un middleware pour ça ?

Hmm je ne sais plus trop. Le seul problème qui me revienne n'est pas lié à Django, je l'ai encore eu récemment en voulant faire autre chose.

Imaginons une page X qui contient deux sous-parties "ajaxifiables" (que j’appellerai "frames") A et B contenant chacune un formulaire. Si je valide le formulaire de A et qu'il y a une erreur de saisie, la frame devrait être affichée à nouveau (avec un petit message d'erreur à côté des champs, par exemple). Par contre, si tout se passe bien, on peut avoir envie de provoquer l'affichage d'une nouvelle page complète, et je ne sais pas comment faire ça autrement qu'avec des hacks (un bout de JS qui, selon la réponse reçue, l'affiche dans la frame ou redirige l'affichage).

J'ai voulu tenter d'utiliser soit une réponse HTTP 200 pour actualiser seulement la frame, soit une réponse HTTP 302 vers l'URL de la page pour actualiser le tout. Mais l'objet XmlHttpRequest n'étant pas capable de ne pas suivre automatiquement les 302 (c'est envisagé pour une prochaine version de la spec.), ça n'est pas possible.

Sinon pour en revenir aux problèmes spécifiques que j'avais avec Django, je ne sais plus trop, je vais retrouver mon code de l'époque et tâcher de me souvenir ^^

[edit] en fait, ce que tu proposes s'approche de la solution n°3 de mon premier post, non ?

Ça ne me choque pas de faire une redirection après une validation de formulaire, c'est même conseillé pour éviter les F5 qui valident à nouveau, non ?

C'est en effet la solution 3, mais avec une solution simple à mettre en œuvre pour ne pas faire les validations à chaque fragment, donc en supprimant son principal problème ^^

Oui, faire une redirection ça me semble être la bonne solution, c'est la mise en oeuvre technique sur laquelle j'ai des doutes ^^

Pour la validation des paramètres des fragments, je n'ai pas trop du comprendre ta question ; chaque fragment au sein d'une page a potentiellement des paramètres qui lui sont propres, ainsi que des paramètres partagés. Je ne vois pas trop comment un middleware peut s'en occuper, à moins d'avoir un middleware par fragment (ce qui rend le middleware inutile, autant faire la validation dans le fragment).

Sinon autre solution : la fonction correspondant à chaque fragment pourrait avoir des décorateurs "validate_machin" pour chaque paramètre à valider. Un middleware (ou n'importe quoi d'autre) aurait pour rôle la récupération de tous les paramètres à valider, en supprimant les éventuels doublons, et l'exécution de ces validateurs.

Zeph (./39) :
Pour la validation des paramètres des fragments, je n'ai pas trop du comprendre ta question ; chaque fragment au sein d'une page a potentiellement des paramètres qui lui sont propres, ainsi que des paramètres partagés. Je ne vois pas trop comment un middleware peut s'en occuper, à moins d'avoir un middleware par fragment (ce qui rend le middleware inutile, autant faire la validation dans le fragment).

Tout dépend du nombre total de paramètres possibles, et j'étais dans l'idée que les paramètres allaient souvent être les mêmes

Si on a 10 fonctions qui se partagent une quinzaine d'arguments différents (genre fonction_1(a, b, c), fonction_2(b, c, d), fonction_3(d, e, f), ...), le middleware peut tout à fait valider tous les arguments (**kwargs ftw).
Après, tu peux également utiliser les décorateurs, en effets.

Là où le middleware est indispensable, c'est pour la mise en forme de la réponse, pour transformer l'objet Python en JSON encapsulé dans une HttpResponse.