Architecture MVC client server

suite à une petite discussion ici
http://www.developpez.net/forums/d94...ations-separes

j'ai abordé mon approche MVC
je pense que cela ferait bien un article en attendant voici ce que je fais.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66

+------------------+ +-------------------------+ +------------------------+ +---+ | | | | | | | | | application View | | module view | | module view | | | | | | | | | | N | +------------------+ +-------------------------+ +------------------------+ | A | +------------------+ +-------------------------+ +------------------------+ | V | | | | | | | | I | | front controller | | module Controller | | module Controller | | G | | | | | | | | A | +------------------+ +-------------------------+ +------------------------+ | T | +------------------+ +---------------+ +----------------+ +---------------+ | E | | | | | | | | | | U | | Core framwork | | Objet model | | Objet model | | Objet model | | R | | | | | | | | | | | +------------------+ +---------------+ +----------------+ +---------------+ | | +-------------------------------------------------------------------------+ | | | | | | | extjs | | | | | | | +-------------------------------------------------------------------------+ +---+ ^ | HTTP v +-----------------+ +-----------------------------------------------------+ +---+ | | | | | | | View | | services provider | | | | | | | | | +-----------------+ +-----------------------------------------------------+ | | +-----------------+ +-------------------------+ +-------------------------+ | | | | | | | | | | | Controller | | service controller | | service controller | | | | | | | | | | S | +-----------------+ +-------------------------+ +-------------------------+ | E | +---------------+ +-----------------+ +-----------------+ +---------------+ | V | | | | | | | | | | E | | Objet model | | Objet model | | Objet model | | Objet model | | U | | | | | | | | | | R | +---------------+ +-----------------+ +-----------------+ +---------------+ | | +---------------+ +-----------------+ +-----------------+ +---------------+ | | | | | | | | | | | | | Persistance | | Persistance | | Persistance | | Persistance | | | | | | | | | | | | | +---------------+ +-----------------+ +-----------------+ +---------------+ | | +-------------------------------------------------------------------------+ | | | | | | | Zend Framwork | | | | | | | +-------------------------------------------------------------------------+ | | +-------------------------------------------------------------------------+ | | | | | | | PHP | | | | | | | +-------------------------------------------------------------------------+ | | +----------------------+ +----------------------+ +-----------------------+ | | | | | | | | | | | LDAP connector | | DB connector | | ... connector | | | | | | | | | | | +----------------------+ +----------------------+ +-----------------------+ +---+ ^ ^ ^ | LDAP | TCP | ... v v v +----------------------+ +----------------------+ +-----------------------+ | | | | | | | resource LDAP | | ressource DB | | ressource ... | | | | | | | +----------------------+ +----------------------+ +-----------------------+

---

j'utilise donc MVC côté serveur pour lancer mon IHM et pour la fourniture de service
et MVC côté client aussi la seule différence c'est que la persistance des objet model côté client se fond par invocation de service

pour le moment j'utilise simplement Http GET POST pour mes échanges en JSON
mais j'envisage d'utiliser REST

j'utilise aussi beaucoup de design pattern façade
A+JYT

salut,

si tu écrit un article sur ce sujet, n'hésite pas à mettre un lien ...:ccool:

sinon, t es, objet model sont identique cote serveur et client ... ?

non pas nécessairement

en fait je considère que le client et le serveur sont deux appli qui communiquent ensemble via des services

A+JYT

Bonjour

Je n'ai pas vraiment le temps de faire un article complet
Je vais donc vous donner par morceau dans cette discussion les éléments de mon approche.

Tout d'abord je plante le décor.
J’ai commencé à travailler sur cette approche avec ZF 1.0.4
La partie serveur se base donc dessus et dans cette version de ZF les services n'étaient pas très souples
J’ai donc utilisé des contrôleurs MVC de ZF pour faire des services retournant du JSON (suppression de la vue et retour de JSON)
Le fonctionnement est simple
Une URL à la ZF standard renvois un flux JSON à la place d'une page HTML

Pour ceux qui ne connaissement pas ZF utilise des utl du type
BaseURL/Module/Controller/Action/param1/value1/param2/value2
J’ai donc décidé de faire mes services de la sorte.

L'API REST par exemple de ZF 1.10 c'étant très largement amélioré
Il serait intéressant de passer de
BaseURL/Module/Controller/Action/param1/value1/param2/value2 à BaseURL/Module/Controller/
Où l'action est un verbe REST et la param passé dans le corps de la requête (comme en POST)

Je n'entre pas dans les détails de cette partie car ce ne sera pas le sujet aujourd'hui. Je le cite juste pour que vous compreniez mes urls.

Je bâtis mes Applis en Full Ajax. J’ai donc une page qui charge l'IHM et ensuite tout se fait pas Extjs.
Cette page va simplement charger les libs et autres JS nécessaires et lancer le client.

J’ai un petit script qui prépare l'espace de travail et qui lance le où les composants de départ.

Je vais vous parler de la structure de ses composants.
Cela correspond au sommet du diagramme que j'ai posté en tout début de cette discussion.

Je découpe mes composants en trois parties chaque composant est le plus indépendant possible. C’est une unité fonctionnelle au sans de l'utilisateur.

La première partie le contrôleur se charge de la cinématique et de la coordination. C’est lui qui est lancé au départ.
À lui de charger et instancier les éléments nécessaires.

Vient ensuite le modèle qui permet la manipulation des données. Et la vue qui permet de les présenter.

Je ne créé JAMAIS de variable globale j'attache tous mes composants à un seul est unique Objet : Ext.app.
La destruction de cet objet nettoie tout la mémoire.

Je distingue deux types de contrôleur, les contrôleurs uniques et ceux pouvant être instancier en plusieurs exemplaires.

Je vais prendre un exemple pour illustrer tout ça que je reprendrait au fil des ajouts.

Soit donc une application permettant de gérer ses contacts
J’ai donc un carnet de contact et des contacts.

Pour représenter le carnet dans mon application j'ai un composant contactList qui n'existe qu'en un seul exemplaire (singleton)
Par contre les contacts sont représentés chacun par une instance de contact.

Je vais donc avoir
Une classe Contact pour le contrôleur une vue contact et un modèle contact
De même je vais avoir un objet contactList une vue contactList et un modèle. (Qui peut ou pas être le même que celui de contact.)

Voici la définition de mon contrôleur contactList

Code:

---

1 2 3 4 5 6 7 8 9 10 11

// Contact List Ext.app.ContactList = Ext.apply(new Ext.app.Controller(), {   scripts: { model: Ext.app.modelDir + 'ContactList.js', window: Ext.app.viewsDir + 'ContactListWindows.js' }, run: function(){ ... } }

---

Ext.app.ContactList est un objet.

De même pour les contact

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

Ext.app.Contact = function(cfg) { Ext.app.Contact.superclass.constructor.call(this); //set config Ext.apply(this, cfg);   this.scripts.locale = this.getLocalScript('Contact'); ... this.fireEvent('ready'); }   Ext.extend(Ext.app.Contact, Ext.app.AbstractController, { scripts: { model: Ext.app.modelDir + 'Contact.js', window: Ext.app.viewsDir + 'ContactWindows.js' },   sources: {},   idPrefix: 'contact-win' });

---

Ext.app.Contact est cette fois un classe qui me permettra d'avoir plusieurs contacts ouvert en même temp.

Pour lancer contactList il suffit de faire

Code:

---

Ext.app.ContactList.run();

---

et pour les contacts

Code:

---

1 2	var aContact = new Ext.app.Contact({id: 45}); aContact.run();

---

aContact et Ext.app.ContactList sont tous deux des contrôleur et ont les même méthodes. Cela simplifie le développement.
C’est ainsi que j'ai capitaliser pas mal de chose vous avez sûrement remarque Ext.app.AbstractController et Ext.app.Controller
Le premier est un contrôleur abstrait et le deuxième dérive du premier pour permettre la fabrique de singleton.

Que ce passe-t-il lors du "run" ?

La première chose que va faire le contrôleur c'est de vérifier qu'il a son modèle et sa vue.
Si ce n'est le cas il charge le script nécessaire pour cela j'ai une méthode dans Ext.app.AbstractController

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

loadSource : function (cfg) { if (undefined == this.sources[cfg.name]) { Ext.Ajax.request({ scope: this, disableCaching: false, url: cfg.source, cfg : cfg ,failure: function(response, requester){ Ext.notif(requester.url, response.statusText); }, success: function(response, requester){ this.constructor.prototype.sources[requester.cfg.name] = true; try { eval(response.responseText); requester.cfg.success(this); this.fireEvent(requester.cfg.event); } catch (e) { Ext.notif(requester.url, e); } } }); } else { cfg.success(this); this.fireEvent(cfg.event); } },

---

Il faut noter que cette méthode est attachée à la classe ce qui fait que les modèles et vues ne sont chargé qu'une seule fois et uniquement si on se sert un fois du contrôleur.

Certain d'entre vous aurons remarqué la présence d'évènements bien que nous ne parlions pas encore d'IHM.
C’est un moyen simple efficace de découpler les éléments tout en permettant d'enchaîner la dynamique.
Le cycle de vie du contrôleur et ainsi ponctué d'évènement. On peu donc s'y abonner pour réagir sans savoir à le modifier.
La liste est la suivante
- modelLoaded
- localeLoaded
- viewLoaded
- activated
- ready
- close
Le chaînage se fait simplement par

Code:

---

1 2 3

this.on('modelLoaded', this.loadLocale, this); this.on('localeLoaded', this.loadView, this); this.on('viewLoaded', this.activate, this);

---

Etc. on peut facilement réorganiser ces enchaînements en fonction de ses propres besoins.
Autre avantage si on chaîne beaucoup de méthodes qui sont longues, l'IHM reste réactive.
La façon habituelle aurait été de faire une succession d'appel aux différentes méthodes. S’il y en a beaucoup, l'exécution prend du temps et l'utilisateur est bloqué et ne peut rien faire.
En passant par des évènements chaque fois qu'une étape est franchie elle poste un évènement et rend la main.
Si l'utilisateur à déclanché un autre évènement celui-ci entre dans la file des évènements et sera exécuté.
L’utilisateur n'est donc pas bloqué. (Il faudra attendre HTML 5 pour pouvoir faire du multitread en JS en attendant on partage le temps)

À quoi ressemble le modèle ?
Le modèle est un objet qui contient les méthodes pour manipuler les données. Il va s'occuper de la persistance des règles métiers etc.
Il faut donc instancier ce modèle pour s'en servir. Mon fichier modèle sera donc une méthode sur le composant qui servira de fabrique
Voici donc par exemple la fabrique de modèle de contact list
Une liste de contact est une structure hiérarchique qui offre le service de supprimer un élément.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

Ext.app.ContactList.getModel = function(controller) { return { // lecteur de données. dataReader: new Ext.tree.TreeLoader({ url: Ext.app.baseUrl + 'contact/getList/', requestMethod: 'GET', preloadChildren: true, clearOnLoad: false }),   getDataReader: function () { return this.dataReader; },   remove: function (id, scope) { Ext.Ajax.request({ scope: scope, disableCaching: true, url: Ext.app.baseUrl + 'contact/remove/id/' + id, success:scope.removeSuccess, failure:scope.removeFailure }); } }; }

---

Je vous laisse imaginer tout ce qu'on peu demander comme service à une liste de contact.
Je passe le contrôleur en paramètre pour permettre à la fabrique de piocher les attributs qui lui sont nécessaire pour créer le modèle.
Pourquoi me direz vous puisque la méthode est attachée à ContactList qui est le contrôleur ? Un simple this suffisait.
Simplement pour être homogène. Dans le cas de Contact la méthodes est attacher à la classe et non à l'instance. Étrange me direz vous
En fait la classe charge la méthode après que l'instance ait été crée.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52

Ext.app.Contact.getModel = function(controller) { return { // lecteur de données. dataReader: new Ext.data.JsonReader({ totalProperty: "results", root: "rows" }, Ext.data.Record.create( // format des enregistrements affichés dans le formulaire. [ {name : 'contact_name', mapping: 'contact_name'}, {name : 'contact_firstname', mapping: 'contact_firstname'}, {name : 'contact_mail', mapping: 'contact_mail'}, {name : 'contact_phone', mapping: 'contact_phone'}, {name : 'contact_group', mapping: 'contact_group'}, {name : 'contact_genre', mapping: 'contact_genre'} ]) ),   group: new Ext.data.JsonStore({ proxy: new Ext.data.HttpProxy({ url: Ext.app.baseUrl + 'group/getList/', method: 'GET', disableCaching: false }), autoLoad: true, root: 'rows', totalProperty: 'results', fields: [ {name : 'group_id'}, {name : 'group_name'} ] }),   url: Ext.app.baseUrl + 'contact/' + controller.method + '/id/' + controller.id,   getDataReader: function () { return this.dataReader; },   getGroupStore: function () { return this.group; },   setUrl: function (method, id) { this.url = Ext.app.baseUrl + 'contact/' + method + '/id/' + id; },   getUrl: function () { return this.url; } }; }

---

Pour la vue il en va de même. La méthode getView est attachée dynamiquement et la vue instancié par une fabrique.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

Ext.app.Contact.getView = function(controller) { return { title: controller.locale.title + controller.name, width: 400, height: 230, iconCls: controller.iconCls, shim:false, animCollapse:false, closable:true, resizable: true, constrainHeader:true, bodyStyle:'padding:5px 5px 0', border:false, layout: 'fit', buttonAlign:'center', items: … }; }

---

Il est temps de parler d'un point passé sous silence. Lorsque je démarre un composant je charge aussi et sur le même principe un fichier de locale permettant d'avoir un IHM dans la langue de l'utilisateur.
Vous avez peut être remarqué le this.getLocalScript('Contact'); au tout début
Cette méthode donne le nom du fichier de locale associé au composant pour la langue de l’utilisateur. Ce fichier est attaché au contrôleur avant le chargement de la vue.
L’instanciation de la vue se fait donc directement dans la langue de l'utilisateur.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

Ext.app.Contact.locale = { title: 'Contact : ', wait: { title : 'Veuillez Patienter', msg: 'SVP .....' }, genre: [ ['0', 'Homme'], ['1', 'Femme'], ['2', 'Enfant'] ], save: 'Enregistrer', reset: 'RaZ', empty: 'aucune donnée disponible', messages: { errorTitle: 'Contact : erreur', UNAVALABLE: 'le service est actuellement indisponible', dataLoaded: 'les donnes on été chargées' } }

---

C’est déjà beaucoup pour aujourd'hui
Un petit résumé de la structure

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

| +---controller | AbstractController.js | Contact.js | ContactList.js | Controller.js | +---locales | Contact-en.js | Contact-fr.js | Contact-ja.js | ContactList-en.js | ContactList-fr.js | ContactList-ja.js | +---model | Contact.js | ContactList.js | +---views ContactListWindows.js ContactWindows.js

---

A+JYT

Alors là, respect :hola:

Je viens justement de commencer à utiliser extjs depuis quelques semaines pour une appli dont l'IHM sera aussi full extjs et le serveur en ZF.

Passé la première phase de prototypage pour se familiariser à extjs, j'ai refondu le code pour le rendre OO aussi, mais j'avoue que là tu m'as clairement dépassé :oops:

En fait nous on a créé des classes de base dérivées de Ext.Window, Ext.form.FormPanel, Ext.grid.GridPanel etc. pour les adapter aux besoins de l'appli (exemple un composant qui gère une grid et un form pour l'édition, avec boutons add/remove dans la toolbar). Ensuite chaque fenêtre de notre appli étend notre classe App.Window et utilise nos classes principales pour construire des fenêtres-types en un minimum de code (code qui se résume essentiellement à écrire des directives de config).
Pour les forms, on a écrit une classe PHP dérivée de Zend_Form qui convertit un form ZF en array de config au format extjs, accessible par une vue qui convertit l'array en json grâce au helper $this->_helper->json($array) :)
Le json est ensuite récupéré en ajax par nos classes js, décodé, et le tout est ajouté au panel qui va bien. Côté serveur cela permet de traiter le submit du form de manière classique dans le contrôleur PHP, notamment en profitant des validateurs ZF.

Voilà, c'est résumé et clairement moins poussé que ton archi, mais comme ça on partage nos approches pour une utilisation rationnelle d'extjs :D

j'ai moi aussi séparé le form de la vue
mon form est aussi une description JS
mais je n'ai pas été jusqu'à utiliser ZF_Form
(il faut dure qu'en 1.0.4 ZF ne proposait pas le composant)
mais c'est une chose à la quelle j'ai pensé.

je réfléchi en ce moment à une autre façon de charger les scripts dynamiquement
(ma méthode se heure à des pb lorsque les script sont très gros sous IE apparemment eval n'est pas cool)

j'expérimente une possibilité avec un taskrunner exemple

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35

Ext.app.FrontController = Ext.apply(new Ext.app.Controller(), { scripts: { startMenu : Ext.app.systemDir + 'StartMenu.js', TaskBar : Ext.app.systemDir + 'TaskBar.js', desktop : Ext.app.systemDir + 'Desktop.js', applications : Ext.app.systemDir + 'Application.js' }, ... loadSystem : function () { var head = Ext.getDom(Ext.query('head')[0]); Ext.iterate(this.scripts, function(key, value, object) { var link = document.createElement('script'); link.setAttribute('type', 'text/javascript'); link.setAttribute('src', this.scripts[key]); head.appendChild(link); }, this);   this.waitLoadScripts(); },   waitLoadScripts: function(){ this.waitingTask = { run: function(){ if ((undefined != Ext.Desktop) & (undefined != Ext.ux.StartMenu) & (undefined != Ext.app.Application) & (undefined != Ext.ux.TaskBar)) { Ext.TaskMgr.stop(Ext.app.FrontController.waitingTask); Ext.app.FrontController.fireEvent('systemLoaded', Ext.app.FrontController); } }, interval: 1000 // 1 seconde }; Ext.TaskMgr.start(this.waitingTask); },

---

j'attache les script que je veux charger par des objet DOM script puis je lance une tache toute les secondes qui vérifie que les objet attendus existe
lorsque tout est charger la tache s'autodétruit et lance un évènement comme quoi c'est prêt.

de la sorte je peux définir un boot de mon appli Extjs qui ne charge que le strict nécessaire et qui lorsque l'utilisateur vas invoquer un composant va charger les script nécessaires. l'appli n'activera alors le composant que lorsque les scripts seront effectivement présent.

c'est pour le moment expérimental mais je n'ai pas trouvé mieux pour faire l'équivalent d'un import dynamique.

si cela s'avère efficace j'essaierai de rendre le truc réutilisable dans une classe de base.

A+JYT