Zend FR

Ton approche est est super intéressante. Dans une version ultérieure, je voudrais déporter le plus possible de traitements vers le client. Ton architecture me semble trés solide.

Penses-tu qu'il est envisageable de ne renvoyer au client que des données codées en JSON et que le javascript se charge de mettre à jour la page ?

Quand je fais un profile de mon appli, la majeur partie du temps consommé est consacrée au rendu des templates par Smarty. En plus ça permettrait d'alléger la charge serveur.

J'imagine donc d'afficher une première fois ma page en html, puis les requêtes suivantes ne retourneraient que données, charge au Javascript de les dispatcher. Mais il ya tellement de cas différents que j'ai préféré dans un premier temps m'en remettre entièrement à retourner du HTML. Toutefois, j'ai bien séparé les traitements, ce qui me permettrait de basculer en douceur vers une délégation des traitements les plus lourds vers le côté client.

Ca te parait faisable de manière assez générique ?

Fred

Dernière modification par fred wolf (03-07-2007 11:18:45)

Hombre, tu dégaines plus vite que ton ombre ! Déjà une réponse avant la fin de ma question...J'ai fait une erreur de manip j'ai posté avant d'avoir terminé.

Comment envisager le traitement javascript ? Une fois je renvoie des data à mettre dans des td, une autre fois dans des input (text, select, textarea) ou encore dans le href d'un lien. Le serveur doit-il détailler au client le container de chaque donnée ou le client peut-il s'appuyer par exemple sur le fichier js que tu mentionnais lors du premier chargement ?

Si j'ai bien compris ton principe, la partie vue de ton mvc, produit du html ? Un peu comme un moteur de templates côté client qui se chargerait de créer à la volée du html en le nourrissant avec les data retournée par le serveur ?


Fred

Bonjour capharnaeum,

En fait ajax revient à faire des interfaces lourdes (du client-serveur). Donc on a des exemples complets et très propres de ce qu'on pourrait faire avec swing en java par exemple. Le problème est que javascript a des performances catastrophiques et une couche objet très pauvre. J'ai tendance à penser qu'il ne faut pas pousser le purisme trop loin.
Moi j'ai choisi une "micro-couche" MVC client de 2ko qui répond à mes besoins, mais sans aucun widget de base. Si tu veux des frameworks plus évolués, il y a effectivement Yahoo UI, les API Google, Dojo et Backbase qui proposent des frameworks en plus de leurs widget (il y en a sans doute d'autres...)

Fred,

Pour répondre à ta question :
- quand le serveur renvoie des données au modèle (au modèle javascript), le "content" du modèle est mis à jour. Ensuite on appelle la fonction toUI() qui injecte les données dans le code HTML. (On peut sous-classer ce modèle pour changer le contenu de toUI())
- Le toUI() met à jour le modèle en modifiant directement le DOM. Soit en changeant des values dans un formulaire soit en générant réellement de l'HTML (ajout d'un node dans un arbre par exemple...).

Ca ne pose aucun problème que le même service soit appelé par 2 modèles différents. Donc si tu veux afficher tes données différemment, tu peux créer un autre modèle et changer le toUI().

A+, Philippe

Tiens pour ceux qui veulent en savoir plus sur Javascript (je ne sais pas sis vous avez remarqué, mais ma spécialité c'est de parler une fois sur deux d'un truc qui n'a rien à voir avec le Framework....), c'est un site qui regroupe des videos comment dirais-je, éducatives, sur pleins de thèmes et notamment sur la programmation.
C'est un peu comme si vous étiez en formation :
Programming Video Education Lectures

fred