Zend FR

Salut à tous

j'ai depuis début septembre commencé un projet d'envergure à base de ZF et Ajax
j'ai commencé par présenter une maquette Ajax en mode bouchon
puis j'ai intégré la chose à ZF
et enfin j'ai branché le tout sur une base Oracle

je ne savais pas trop où mettre cet article.
la première étape donc une maquette en javascript full Ajax l'application à donc une seule page html
celle-ci affiche un div contenant une image animé pour patienter. derrière ce div on y trouve une série de javascript à charger. de cette façon l'image s'affiche avant le chargement de script et l'utilisateur voit quelque chose en attendant. lorsque les élément de base sont près le dernier script instancie l'application ajax et remplace le div par le contenu de l'IHM. il n'y a donc pas de HTML (ou presque dans le code). le reste des composant nécessaire à l'application seront chargés de façon asynchrone. j'ai utilisé la librairie ExtJs issue de la libération de la lib de Yahoo en version 2.0.2. je vous laisse aller voir par vous même: http://extjs.com.

pour ma maquette j'ai donc développé en une semaine l'architecture générale de mon ihm. les données devant s'y intégrer étant chargé de façon asynchrone en les demandant au serveur. j'ai donc fais comme si je disposait du serveur et j'ai mis les urls telles que je pensais les avoir. c'est a dire comme si elle était faites pour ZF.

J'ai donc mis dans mon site des dossiers et sous dossier correspondant aux url de mes contrôleurs et actions
par exemple http://server/client/getAll/ donne le dossier client contenant le dossier getAll
et pour que cela me retourne des données un fichier .htaccess contenant un défaultIndex à index.json et un fichier index.json contenant le texte JSON telque devrait me le donner le serveur.

en une semaine j'avais donc un quinzaine de faut json de ce type et un IHM dynamique assez parlant pour le client.

ExtJS est basé su un paradigme MV plus que MVC le seul élément de contrôle que l'on trouve est l'objet Ajax. et généralement on mappe les donnée sur des éléments d'IHM de même on place du code dans les event des objets. J'ai mis en place une notion de Contrôleur plus claire mais par manque de temps je ne l'ai pas finalisé. en gros je crée un objet JS chargé de garder les références au données nécessaire, de faire les mapping, et de fournir les méthode nécessaire au traitement des événements. ainsi si un même traitement doit être fait à partir de plusieurs événements il est codé dans une seule méthode.

Voilà c'est tout pour la partie JS. vous aurez compris que tout cela cause avec le serveur en JSON. mais il est aussi possible de le faire en XML ou tout autre protocole d'échange de donnée accessible par XMLHttpRequest.

étape suivante intégration de ZF. vous aurrez compris que cela fut simple vu que j'avais prévu les bonnes url. j'ai donc construit une application ZF qui ne renvoi qu'une seule vue sur l'action par défaut. cette vue étant la page html de mon IHM. au passage j'ai ajouté quelque passage d'information entre ZF et ExtJs c'est fort simple
une simple affectation de valeur dans un tag script de la vue.
Pour me facilité le travail j'ai fais un objet params que j'ai encodé en JSON et affecté à une variable js dans la vue. le javascript interprétant le JSON naturellement c'est une affectation de tout un objet complexe avec sous objet qui est passé d'un coup.

je me suis posé la question de comment fournir les données à mes appels ajax ZF fourni pour cela des classes mais j'ai préféré gardé la structure MVC j'ai donc choisit d'en passer par des contrôleurs et des actions.
elle n'ont qu'une seule particularité la vue n'est pas en HTML mais en JSON. le mécanisme de vue de ZF est alors beaucoup trop complexe pour un besoin aussi simple.
j'ai donc choisit de le remplacer par autre chose. et voilà à qui je suis arrivé.
une classe Application_Ajax dérivant de Zend_Controller_Action. dans la methode init de celle-ci un
setNoViewRenderer, la création d'un objet stdClass $response et une surcharge de la méthode postDispatch.

je me suis dit qu'il serait plus lisible de faire des affectation à $this->response plutôt qu'à $this->view cela enlève de la confusion. (la réponse étant du JSON alors que la vue est une vue au sens ZF) dans les fait ça fonctionne de la même façon.
le postDispatch lui va vérifié que l'appel à été fait en XmlHttpRequest si c'est le cas il envoie un header application/json sinon text/plain. puis il écrit sur la sortie
echo Zend_Json::Encode($this->response);

ainsi lorsque l'application invoque le service elle reçois la réponse en json et si pour tester on l'appelle dans le navigateur on voit le JSON à l'écran en clair.

la suite à donc été d'écrire des contrôleurs dérivant de Application_Ajax et des actions tout ce qu'il a de plus classique en ZF

gardant mes habitude dans ZF j'ai mis en place une façade pour l'accès au méthode métier. dan sun premier temps cette façade fonctionnait en mode bouchon. (le temps que le DBA oracle me fournisse la base)

les avantage que j'ai trouvé à cette approche ont été la possibilité d'utiliser les pleines capacité de ZF pour la partie MC, la vue étant réduite à sa plus simple expression.
la gestion de la sécurité, les composants métier, les filtres etc. et le travail en mode bouchon.

J'ai à ce stade là pratiquement arrêté dynamique de l'application. l'ajout d'une nouveau composant se faisant par la création de l'IHM approprié en JS et la création d'un nouveau contrôleur ou l'utilisation des contrôleur existants.

la dernière étape fut la réalisation de la couche métier. elle est parfaitement identique à ce qu'elle aurait été avec une application MVC classique. mais j'ai rencontré quelques difficulté avec Oracle et l'adaptateur pdo oci. pas très simple de comprendre certaine erreurs j'ai par exemple une vue qui fait des agrégats et je devais y piocher certaine donnée j'ai eu droit à une exception à propos d'un mauvais un usage de ROWID or je n'utilise pas ROWID. ne comprenant pas j'ai remplacé la chose par un SELECT * FROM mavue; écrit en dur dans le code et j'avais la même exception. Alors que ma requête fonctionne parfaitement dans SQL. j'ai fini par abandonner faute de temps et mettre ma requête d'agrégat directement dans le code et supprimer la vue. et là ça marche. à par ce gendre de truc pas de souci particulier.

j'ai donc dans mon application une partie client riche en ExtJS qui gère environs 100 composant complexe. le tout est chargé au démarrage puis de façon asynchrone en fonction des besoin.
chaque instence d'un composant invoque les service ajax qui lui son nécessaire au travers de ZF qui va utiliser la couche métier puis la couche de persistance.

J'avais une crainte concernant les perf. il n'en est rien. chaque appel ajax même ceux qui demandent le plus de charge durent environ 400ms l'interface est très fluide et le fonctionnement asynchrone très agréable. la charge réseau est particulièrement faible car ne transite que les données nécessaires.

j'ai fait attention à bien utiliser le cache du navigateur ainsi je n'ai aucun composant js qui est généré en php ils sont tous statique et donc mis en cache. seules les données sont fournies dynamiquement et donc pas mise en cache. ExtJS fournis un argument pour géré cela facilement.

je n'ai pas encore fini l'application et travaille donc en mode débug. mais j'ai tout de même fait des test en utilisant un outil pour minimiser le code javascript. celui-ci prends le code JS et le débarasse de tout ce qui n'est pas utile. il remplace les noms de variable pour les réduire au mieux. les fichier fondent comme neige au soleil et l'interprètes js de IE FF ou safari semblent y être sensible.
j'ai aussi regardé s'il ne serait pas intéressant de gzipper les fichier js.
là je suis plus réservé.
utiliser la compression n'est intéressant que sur les fichiers statiques. elle implique une surcharge sur les données dynamiques. mais même sur les fichiers statiques le résultat n'est pas très pertinent.

j'ai mis les fichiers déjà gzippés sur le serveur. il n'y a pas de charge de ce côté là. le transfert est effectivement plus rapide. mais le navigateur doit décompacter à l'arrivée. et au total le temps et identique ou presque.

on ne gagne que sur la charge réseau.
je le conseille donc sur des transfert lourd sur internet car là le temps de transport impacte directement les perf. dans mon cas sur un intranet ce n'est pas le cas.

Voilà un premier bilan de ce développement.
je dois dire que je suis agréablement surpris par la facilité que j'ai eu à mettre ça en place.

A+JYT