Consultez la FAQ sur le ZF avant de poster une question
Vous n'êtes pas identifié.
A mon avis le validateur W3C il doit clignoter de partout ...
Hors ligne
Et quand a utiliser une extention type TIDY, ca doit pas être gagné non plus
Hors ligne
TiTerm a écrit:
Les validateurs t'insultent pas quand tu soumets des NS perso comme ca ?
non si ton namspace est correctement déclaré et que tu fournis le shemas qui vas avec
J'ai répondu rapidement et j'ai lu les messages suivants. le W3C a prévu l'utilisation de namspaces justement pour ajouter des attribut et des tag dans un document XML
bien évidement le W3C fournis des validateur pour ses propres Shémas mais la norme permet de définir les sien heureusement car il n'y aurait pas de XML
pour valider un tel document il faut fournir au validateur le shemas complet c'est à dire celui du document de base plus celui de tous les namespaces
en fait un validateur lit un shémas et vérifie que le document est conforme à ce shémas. si tu fournis le shémas de tes propre délire tant qu'il son conforme à la syntaxe XML tu peux faire ce que tu veux.
enfin utiliser un namspaces permet de spécifier des attribut qui son propre à un usage et de ne pas détourner les attributs de leur usage premier.
A+JYT
Dernière modification par sekaijin (07-11-2007 20:14:17)
Hors ligne
Bah normalement, tes schemas sont fournis par la déclaration de ton NS. Mais j'ai pas encore trouvé de validateur qui prenait ca en compte. Ca peut se faire en XHTML mais le html, c'est beaucoup moins strict et du coup, c'est pas gagné. J'avais essayer un truc du genre a une époque sans succès. Idem avec tidy. Il se contrefous du fichier que tu fournis, il valide suivant ce qu'il connait.
Hors ligne
oui à par quelques outils pro et cher genre spyxml je ne connais pas de validateur qui acceptent complètement les normes XML il faut dire que c'est un sacret foutoir. à tel point que lorsque j'ai un stagiaire qui viens travailler chez moi. pour lui faire peur je lui montre mon poster du diagramme des normes XML et je lui dis que pour commencer il a deux jours pour retenir la chose. ça rate jamais.
mais bon on arrive à faire avec.
l'important là c'est que ça fonctionne sans perturber le reste (entre autre les transformations XSLT qui elle aussi jouent de namespaces)
A+JYT
Hors ligne
Comment tu fait pour declarer des nouveaux attributs aux balises et que ce soit valide ?
ca m'interesse pas mal ca. Ca m'evitera de détourner des attributs ...
Il y a un tuto la dessus quelque part ?
Merci.
Hors ligne
ben à part les doc du W3C sur les namespaces non
J'avais trouvé un doc sur msdn traitant des namespace et xmlshemas mais il n'est plus en ligne et je ne l'avais pas copier.
avec un DTD il faut écrire une DTD complète qui contient la définition de tous tes tag et attributs y compris ceux du doc de base XHTML
A+JYT
Hors ligne
Hum ca parait quand même fastidieux comme truc, je vais essayer de trouver des exemples sur le web.
Merci pour l'info.
Hors ligne
Bon be c'est pas gagné.
Je voudrais juste rajouter un attribut ou 2 à une ou deux type de balise. genre les div et les a
Be va comprendre comment faire ... y a quelques trucs sur le web mais rien de trés clair, ca m'a quand même l'air d'être fastidieux et compliquer pour ajouter 3 pauvres attributs, dommage
Hors ligne
ne les ajouter c'est simple faire un validateur qui les accepte ça c'est pas gagné
sinon il te suffit de faire ça
<div xmlns:prefix="mun.urn.a.moi" prefix:myattribute="value">
et si tu veux éviter de re-déclarer ton namespace tu le mets sur le tag-root de ta page c'est tout.
tu n'est pas tenu de fournir un url comme urn par contre c'est une Universal Resource Name
C'est donc un nom Universelllement unique c'est pourqoui on utilise généralement des chose comme
com.mySociété.name.subName
car cela corresponds au nom de domaine de la société qui produit le name space et à sa nomenclature
en fait tu mets ce que tu veux le seul truc c'est que si tu mets une urn qu'un autre définit aussi ailleurs pour autre chose tu ne pouras pas avoir un document qui mixe les deux.
Reste le pb de la validation et là les outils sont rares et chers
A+JYT
Mais le sujet est les toolkit JS
Hors ligne
Juste pour info, Dojo est sorti en version 1.0.0 depuis déjà quelques temps
Le système des dijit est sympa et surtout on peut en ajouter assez facilement.
Hors ligne
Jquery pour moi aussi
Hors ligne
Jquery (PRATIQUE et BEAU)
Hors ligne
salut depuis que j'étais intervenu il y a eu chez moi du changement
exit JQuery
exit le HTML
Je dois dire que je n'ai pas abandonné JQuery parce que ce n'est pas une bonne lib. je lui fais qu'un reproche le manque d'homogénéité des wigets, non pas au niveau esthétique mais plutôt dans leur API.
je suis passe à ExtJS car l'approche est 100% JS donc plus de HTML avec des appels à du JS pour modifier la chose. Mais une page HTML vide et du JS pour faire l'interface. L'API est plutôt homogène et c'est bien. (bien que certains détails parfois). la gestion des thèmes permet de choisir son look (très différent d'une install à l'autre) et c'est rapide.
petit blème par rapport à ZF pas intégré à ZF et pas dans la même philosophie. Mais il est facile de consilier les deux.
A+JYT
Hors ligne
Bonsoir,
Pour réagir au message de Sekaijin.
Tu parles d'IHM full JS là, mais dans le cas où tu dois juste enrichir un peu une page (x)Html classique, tu utilises aussi Ext.js ?
J'avoue que de mon côté je ne sais pas trop. J'utilise aussi Ext.js pour certains de leurs composants qui sont très puissants (les grid quel bonheur) et l'api que je trouve bien foutue.
Je suppose que la plupart des forumeurs qui se sont exprimés ici parle de JS pour agrémenter leurs formulaires (auto-completion, tootip, etc.), faire deux ou trois effets et des requêtes Ajax. Pour ça j'ai toujours utilisé Prototype et scriptaculous, même si je cherche un peu du côté de JQuery en ce moment.
Mais de ton côté ? Quand il s'agit d'apporter un plus (ergonomiquement) sur un formulaire par ex. ?
A+ benjamin.
Hors ligne
JQuery !!
Hors ligne
Pour ma part je débute avec JQuery.
J'ai réellement été impressionné par ce qu'on peut faire avec après avoir vu une démonstration. J'aime bien la syntaxe, l'évolution semble aller dans le bon sens, et on trouve tout un tas de ressources même si c'est pas très organisé pour le moment. De ce que j'en lis, c'est vraiment la bibliothèque Javascript montante.
Hors ligne
Delprog a écrit:
Bonsoir,
Pour réagir au message de Sekaijin.
Tu parles d'IHM full JS là, mais dans le cas où tu dois juste enrichir un peu une page (x)Html classique, tu utilises aussi Ext.js ?
J'avoue que de mon côté je ne sais pas trop. J'utilise aussi Ext.js pour certains de leurs composants qui sont très puissants (les grid quel bonheur) et l'api que je trouve bien foutue.
Je suppose que la plupart des forumeurs qui se sont exprimés ici parle de JS pour agrémenter leurs formulaires (auto-completion, tootip, etc.), faire deux ou trois effets et des requêtes Ajax. Pour ça j'ai toujours utilisé Prototype et scriptaculous, même si je cherche un peu du côté de JQuery en ce moment.
Mais de ton côté ? Quand il s'agit d'apporter un plus (ergonomiquement) sur un formulaire par ex. ?
A+ benjamin.
mes dernier développement étaient en AJAX donc plus de HTML donc pas de HTML à enrichir
J'ai utilisé ExtJS pour enrichir des pages mais ce n'est pas là qu'il se montre le plus efficace.
J'ai écrit avec ExtJS un Framwork MVC en Javascript (ExtJS proposant les outils mais pas le modèle de prog MVC)
j'ai donc des contrôleur en javascript
Ext.app.ContactList = Ext.apply(new Ext.app.Controller(), { sources: {}, scripts: { model: Ext.app.modelDir + 'ContactList.json', window: Ext.app.viewsDir + 'ContactListWindows.json' }, ... }
des modèles qui gèrent l'interaction avec le serveur
{ // lecteur de données. dataReader: new Ext.tree.TreeLoader({ url: Ext.app.baseUrl + 'contact/getList/', requestMethod: 'GET', preloadChildren: true, clearOnLoad: false }), url: '', getDataReader: function () { return this.dataReader; }, setUrl: function (method, id) { this.url = Ext.app.baseUrl + 'contact/' + method + '/id/' + id; }, getUrl: function () { return this.url; } }
des vues qui définissent l'affichage de l'objet
{ id: 'cl-win', title: controller.locale.title, width: controller.width, height: controller.height, x: controller.x, y: controller.y, //iconCls: 'accordion', shim:false, animCollapse:false, closable:false, constrainHeader:true, border:false, layout: 'fit', items: [{ xtype: 'treepanel', id:'im-tree', rootVisible:false, lines:false, autoScroll:true, tbar:[{ id:'refresh', iconCls:'icon_refresh', controller: controller, handler: function() { this.controller.fireEvent('refresh'); } ... }], loader: controller.model.getDataReader(), root: new Ext.tree.AsyncTreeNode({ id:'root', expanded:false //au démarrage pas de donnée disponibles }) }] }
je n'ai donc pas de HTML
Coté ZF j'ai un MVC des plus classique
un contrôleur l'action index génère une vue vide de HTML et active le frontcontrôleur JS
et une action getList qui gère un des appel au métier par le modèle Ajax
<?php class ListController extends Zend_Controller_Action { public function init() { parent::init(); Zend_Loader::loadClass('Model_Group'); $this->model = new Model_List(); } public function indexAction() { $this->_response->setHeader('Content-Type', 'text/html; charset=UTF-8', true); $this->view->baseUrl = $this->_request->getBaseUrl(); } public function getlistAction() { $this->_init(); $sort = $this->_request->getParam('sort'); $dir = $this->_request->getParam('dir'); $count = $this->model->getCount(); $data = $this->model->getData($sort,$dir,0,$count); $this->_setListResponse($data); $this->_postJson(); } ... }
Un appel Ajax est exactement comme pour tout appel battit su MVC de ZF une action pour contrôleur la demande invoquer le métier adéquat et retourner une vue dans ce cas en JSON
dans le cas d'un formulaire c'est la même chose le JS s'occupe de gérer tout l'IHM et communique en ajax avec le serveur il fait lui-même des vérification de saisie. pour il invoque la méthode pour poster les données en Ajax
le contrôleur ZF traite le formulaire comme n'importe quel contrôleur ZF le ferait avec filtrage vérification retour d'erreur et/ou action sur le modèle puis retourne une vue en JSON
Du coup plus besoin de vue en HTML c'est simple c'est rapide c'est évolutif.
effectivement ça sous exploite le capacité de ZF à générer l'IHM mais justement je trouvais que c'était le plus gros point faible de ZF. LA vue est trop souvent trop fortement couplée au contrôleur.
pour vous donner une idée d'une vue en ExtJS voici en entier celle qui gère l'affichage et la saisie des contacts dans mon application
{ 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: controller.form }
et pour le formulaire
{ baseCls: 'x-plain', url: controller.model.getUrl(), defaultType: 'textfield', monitorValid: true, reader: controller.model.getDataReader(), items: [ { fieldLabel: 'name', name: 'contact_name', anchor:'100%' // anchor width by percentage },{ fieldLabel: 'firstname', name: 'contact_firstname', anchor: '100%' // anchor width by percentage },{ fieldLabel: 'phone', name: 'contact_phone', anchor: '100%' // anchor width by percentage },{ fieldLabel: 'mail', name: 'contact_mail', vtype: 'email', anchor: '100%' // anchor width by percentage },{ fieldLabel: 'genre', xtype: 'combo', hiddenName: 'contact_genre', store: new Ext.data.SimpleStore({ fields: ['value', 'label'], data : controller.locale.genre }), displayField: 'label', valueField: 'value', allowBlank: false, //typeAhead: false, //editable:false, mode: 'local', forceSelection: true, triggerAction: 'all' },{ fieldLabel: 'groupe', xtype: 'combo', hiddenName: 'contact_group', store: controller.model.getGroupStore(), displayField: 'group_name', valueField: 'group_id', allowBlank: false, //typeAhead: false, //editable:false, mode: 'local', forceSelection: true, triggerAction: 'all' }], buttons: [ { text: controller.locale.save, formBind: true, type:'submit', name: 'contact_save', controller: controller, handler: function(){ this.disable(); //Ext.notif('save', 'click'); this.controller.saveData(); this.controller.on('saveFailed', this.enable, this); } }, { text: controller.locale.reset, //formBind: true, type:'reset', controller: controller, handler: function(){ this.disable(); //Ext.notif('reset', 'click'); this.controller.loadData(); this.enable(); } } ] }
Voila on peu noter ici la concision pour définir un champs de saisie de type mail par exemple
{ fieldLabel: 'mail', name: 'contact_mail', vtype: 'email', anchor: '100%' // anchor width by percentage }
cela suffit à définir un champ qui filtrera et gèrera seul la conformité de la saisie. pour la saisie de date de ma même manière on obtiendra un calendrier avec gestion des format etc.
A+JYT
Dernière modification par sekaijin (17-06-2009 11:41:03)
Hors ligne
Je comprend bien l'intérêt de ta solution.
Mais tu ne peux appliquer ça qu'à de l'"application" au sens pratique du terme non ? (IHM full JS je veux dire)
Tu ne fais plus du tout de sites web classiques dans lesquels tu utilises JS juste pour améliorer et faciliter l'expérience de l'utilisateur ?
Tu dis "exit JQuery" et "exit HTML", tu fais tous tes sites en full JS maintenant ?
Comme de mon côté j'hésite à utiliser Ext.js comme on utiliserait JQuery pour enrichir des pages et non en IHM full JS, je me demandais, vu que tu as expérimenté les deux en profondeurs apparemment, ce que toi tu privilégies dans ces cas là.
Ext est tellement pratique et les résultats tellement efficaces (point de vu utilisateur) que je me demande si ça vaut pas une petite concession au niveau des performances (toujours quand il s'agit d'enrichir une page, un dateField par ex. :p)
Mis à part ça, ta conception MVC JS est très intéressante !
A+ benjamin.
Hors ligne
Delprog a écrit:
Je comprend bien l'intérêt de ta solution.
Mais tu ne peux appliquer ça qu'à de l'"application" au sens pratique du terme non ? (IHM full JS je veux dire)
Tu ne fais plus du tout de sites web classiques dans lesquels tu utilises JS juste pour améliorer et faciliter l'expérience de l'utilisateur ?
Tu dis "exit JQuery" et "exit HTML", tu fais tous tes sites en full JS maintenant ?
Comme de mon côté j'hésite à utiliser Ext.js comme on utiliserait JQuery pour enrichir des pages et non en IHM full JS, je me demandais, vu que tu as expérimenté les deux en profondeurs apparemment, ce que toi tu privilégies dans ces cas là.
Ext est tellement pratique et les résultats tellement efficaces (point de vu utilisateur) que je me demande si ça vaut pas une petite concession au niveau des performances (toujours quand il s'agit d'enrichir une page, un dateField par ex. :p)
Mis à part ça, ta conception MVC JS est très intéressante !
A+ benjamin.
Je ne fais pas de site que des appli
dans mes dernier développement j'ai effectivement pris le partit du Full JS
dans les versions antérieure j'ai utilisés un mix des deux HTML + ExtJS
déjà par rapport à JQuery mes composant ont été porté sous ExtJS en quelque jours
il ont au passage gagné en ergonomie et en facilité
j'ai bien avant jquery opté pour l'enrichissement de mes page HTML en utilisa des attribut spécifiques dans un namespace plutôt que d'éparpiller du code javascript dans mon HTML
ça donnait quelque chose comme
<form fast:class="AutoForm"> <input type="text" fast:classe="Date" fast:minValue="01/01/2008" />
un JS général lança la fonction JQuery adéquat en fonction de l'attribut.
l'avantage est que sans JS le form reste un form normal et avec il accepte des fonctionnalité enrichies.
quasiment sans changer une ligne dans mon HTML je suis passé à ExtJS à la place de JQuery.
les composant ExtJS sont beaucoup plus richent que ceux que j'avais à l'époque avec JQuery (je ne sais ce qu'il en est aujourd'hui). mais l'usage d'ExtJs ne permets pas très facilement d'exploiter pleinement toutes les fonctionnalités de ExtJS.
pour un data Grid par exemple transformer une table HTML en grid est relativement facile
voici un code qui le fait très bien
<?php class ListController extends Zend_Controller_Action { public function init() { parent::init(); $this->model = new Model_List(); } public function indexAction() { $this->_response->setHeader('Content-Type', 'text/html; charset=UTF-8', true); $this->view->baseUrl = $this->_request->getBaseUrl(); $sort = $this->_request->getParam('sort'); $dir = $this->_request->getParam('dir'); $count = $this->model->getCount(); $this->view->data = $this->model->getData($sort,$dir,0, $count); } }
et le js
Ext.grid.TableGrid = function(table, config) { config = config || {}; Ext.apply(this, config); var cf = config.fields || [], ch = config.columns || []; table = Ext.get(table); var ct = table.insertSibling(); var fields = [], cols = []; var headers = table.query("thead td"); for (var i = 0, h; h = headers[i]; i++) { var text = h.innerHTML; var name = 'tcol-'+i; fields.push(Ext.applyIf(cf[i] || {}, { name: name, mapping: 'td:nth('+(i+1)+')/@innerHTML' })); cols.push(Ext.applyIf(ch[i] || {}, { 'header': text, 'dataIndex': name, 'width': h.offsetWidth, 'tooltip': h.title, 'sortable': true })); } var ds = new Ext.data.Store({ reader: new Ext.data.XmlReader({ record:'tbody tr' }, fields) }); ds.loadData(table.dom); var cm = new Ext.grid.ColumnModel(cols); if (config.width || config.height) { ct.setSize(config.width || 'auto', config.height || 'auto'); } else { ct.setWidth(table.getWidth()); } if (config.remove !== false) { table.remove(); } Ext.applyIf(this, { 'ds': ds, 'cm': cm, 'sm': new Ext.grid.RowSelectionModel(), autoHeight: true, autoWidth: false }); Ext.grid.TableGrid.superclass.constructor.call(this, ct, {}); }; Ext.extend(Ext.grid.TableGrid, Ext.grid.GridPanel);
il faut l'utiliser ainsi
<div id="data"> <table id='the-table' width="600" align="center" border="1" cellspacing="0" cellpadding="7" style="border-collapse: collapse"> <thead> <tr> <td valign="top">Nom</td> <td valign="top">Prénom</td> <td valign="top">Compte</td> <td valign="top">Date</td> </tr> </thead> <tbody><?php foreach($this->data as $item) {?> <tr> <td valign="top" align="center"><?php echo $item['nom']; ?></td> <td valign="top" align="center"><?php echo $item['prenom']; ?></td> <td valign="top" align="right"><?php echo $item['compte']; ?></td> <td valign="top" align="left"><?php echo ereg_replace("([0-9]{4}).([0-9]{2}).([0-9]{2})", "\\3/\\2/\\1",$item['date']); ?></td> </tr> <?php } ?></tbody> </table> </div> <script type="text/javascript"> Ext.onReady(function() { var grid = new Ext.grid.TableGrid("the-table", { stripeRows: true // stripe alternate rows }); grid.render(); }); </script>
on obtient alors un grid qui est plutôt pas mal.
mais si on veut par exemple ajouter le tris sur le compte qui est un tri numérique et non alphabétique ou encore utiliser les renderer pour colorer la valeur en fonction du signe de la valeur etc.
il devient plutôt difficile de faire exactement ce que l'on veut
alors que passer à une version Ajax est bien plus simple
dans cet exemple seul le grid est passé en ajax
<div id="data"> </div> <script type="text/javascript" src="<?php echo $this->baseUrl; ?>/public/scripts/grid.js"></script>
et
/* * Ext JS Library 2.2.1 * Copyright(c) 2006-2009, Ext JS, LLC. * licensing@extjs.com * * http://extjs.com/license */ Ext.onReady(function(){ // example of custom renderer function function change(val){ if(val > 0){ return '<span style="color:green;">' + val + '</span>'; }else if(val < 0){ return '<span style="color:red;">' + val + '</span>'; } return val; } // create the data store var store = new Ext.data.JsonStore({ proxy: new Ext.data.HttpProxy({ url: Ext.app.baseUrl + 'list/getList/', method: 'GET', disableCaching: false }), autoLoad: true, remoteSort: true, root: 'rows', totalProperty: 'results', fields: [ {name: 'nom'}, {name: 'prenom'}, {name: 'compte', type: 'float'}, {name: 'date', type: 'date', dateFormat: 'Y-m-d'} ] }); var pagingBar = new Ext.PagingToolbar({ pageSize: 9, store: store, displayInfo: true, displayMsg: 'Eléments {0} - {1} sur {2}', emptyMsg: "Aucuns élément disponibles" }); // create the Grid var grid = new Ext.grid.GridPanel({ store: store, columns: [ {id:'nom',header: "Nom", width: 160, sortable: true, dataIndex: 'nom'}, {header: "Prénom", width: 75, sortable: true, dataIndex: 'prenom'}, {header: "Compte", width: 75, sortable: true, renderer: change, dataIndex: 'compte'}, {header: "Date", width: 85, sortable: true, renderer: Ext.util.Format.dateRenderer('d/m/Y'), dataIndex: 'date'} ], stripeRows: true, autoExpandColumn: 'nom', height:266, width:600, title:'grille de donnée', // paging bar on the bottom bbar: pagingBar }); grid.render('data'); });
pour un code plus simple plus rapide on obtient un grid avec tri sur es dates sur les nombre coloration des nombres en fonction des signes choix par le client des colonnes affichées ajustement automatique de la largeurs des colonnes, pagination
il faut simplement ajouter la gestion des appels ajax dans le contrôleur.
<?php class ListController extends Zend_Controller_Action { public function init() { parent::init(); Zend_Loader::loadClass('Model_Group'); $this->model = new Model_List(); } public function indexAction() { $this->_response->setHeader('Content-Type', 'text/html; charset=UTF-8', true); $this->view->baseUrl = $this->_request->getBaseUrl(); } public function getlistAction() { $this->_init(); $sort = $this->_request->getParam('sort'); $dir = $this->_request->getParam('dir'); $count = $this->model->getCount(); $start = $this->_request->getParam('start'); $limit = $this->_request->getParam('limit'); $data = $this->model->getData($sort,$dir,$start,$limit); $this->_setListResponse($data, $count); $this->_postJson(); } public function _init() { $this->getFrontController()->setParam('noViewRenderer', true); if ($this->_request->isXmlHttpRequest()) { $this->_response->setHeader('Content-Type', 'application/json; charset=UTF-8', true); } else { // on envoie la reponse en texte lors d'une invocation via le navigateur // cela permet de tester la réponse. $this->_response->setHeader('Content-Type', 'text/plain; charset=UTF-8', true); } $this->response = array(); } public function _postJson() { echo utf8_encode(Zend_Json_Encoder::encode($this->response)); } protected function _setListResponse($data, $count = null) { if (is_array($data) || null != $count) { if (null == $count) { $count = count($data); } $this->response = array( 'success' => true, 'results' =>$count, 'count' =>count($data), 'rows'=> $data ); } else { $this->response = array( 'success' => false, 'error' => 'RES_EMPTY', 'results' =>0, 'count' =>0, 'rows'=> null ); } } }
donc finalement que ce soit en full Ajax ou en mode web je préfaire créer le composant en JS que de modifier du HTML
cela m'a au passage enlevé une épine du pied : la différence d'interprétation du HTML par les navigateur (vu que je n'ais plus de HTML à traiter)
A+JYT
Hors ligne
Pour ma part j'utilise Jquery car j'ai trouvé rapide les éléments dont j'avais besoin pour mon application sur des forum donc je suis rester là dessus. Je trouve qu'il est assez simple d'utilisation pour de petit fonction ajax ensuite je ne l'ai pas essayé sur des éléments plus complexe et je n'ai pas essayé d'autre Tool Javascript
Hors ligne
sekaijin a écrit:
Delprog a écrit:
Bonsoir,
Pour réagir au message de Sekaijin.
Tu parles d'IHM full JS là, mais dans le cas où tu dois juste enrichir un peu une page (x)Html classique, tu utilises aussi Ext.js ?
J'avoue que de mon côté je ne sais pas trop. J'utilise aussi Ext.js pour certains de leurs composants qui sont très puissants (les grid quel bonheur) et l'api que je trouve bien foutue.
Je suppose que la plupart des forumeurs qui se sont exprimés ici parle de JS pour agrémenter leurs formulaires (auto-completion, tootip, etc.), faire deux ou trois effets et des requêtes Ajax. Pour ça j'ai toujours utilisé Prototype et scriptaculous, même si je cherche un peu du côté de JQuery en ce moment.
Mais de ton côté ? Quand il s'agit d'apporter un plus (ergonomiquement) sur un formulaire par ex. ?
A+ benjamin.mes dernier développement étaient en AJAX donc plus de HTML donc pas de HTML à enrichir
J'ai utilisé ExtJS pour enrichir des pages mais ce n'est pas là qu'il se montre le plus efficace.
J'ai écrit avec ExtJS un Framwork MVC en Javascript (ExtJS proposant les outils mais pas le modèle de prog MVC)
j'ai donc des contrôleur en javascriptCode:
Ext.app.ContactList = Ext.apply(new Ext.app.Controller(), { sources: {}, scripts: { model: Ext.app.modelDir + 'ContactList.json', window: Ext.app.viewsDir + 'ContactListWindows.json' }, ... }des modèles qui gèrent l'interaction avec le serveur
Code:
{ // lecteur de données. dataReader: new Ext.tree.TreeLoader({ url: Ext.app.baseUrl + 'contact/getList/', requestMethod: 'GET', preloadChildren: true, clearOnLoad: false }), url: '', getDataReader: function () { return this.dataReader; }, setUrl: function (method, id) { this.url = Ext.app.baseUrl + 'contact/' + method + '/id/' + id; }, getUrl: function () { return this.url; } }des vues qui définissent l'affichage de l'objet
Code:
{ id: 'cl-win', title: controller.locale.title, width: controller.width, height: controller.height, x: controller.x, y: controller.y, //iconCls: 'accordion', shim:false, animCollapse:false, closable:false, constrainHeader:true, border:false, layout: 'fit', items: [{ xtype: 'treepanel', id:'im-tree', rootVisible:false, lines:false, autoScroll:true, tbar:[{ id:'refresh', iconCls:'icon_refresh', controller: controller, handler: function() { this.controller.fireEvent('refresh'); } ... }], loader: controller.model.getDataReader(), root: new Ext.tree.AsyncTreeNode({ id:'root', expanded:false //au démarrage pas de donnée disponibles }) }] }je n'ai donc pas de HTML
Coté ZF j'ai un MVC des plus classique
un contrôleur l'action index génère une vue vide de HTML et active le frontcontrôleur JS
et une action getList qui gère un des appel au métier par le modèle AjaxCode:
<?php class ListController extends Zend_Controller_Action { public function init() { parent::init(); Zend_Loader::loadClass('Model_Group'); $this->model = new Model_List(); } public function indexAction() { $this->_response->setHeader('Content-Type', 'text/html; charset=UTF-8', true); $this->view->baseUrl = $this->_request->getBaseUrl(); } public function getlistAction() { $this->_init(); $sort = $this->_request->getParam('sort'); $dir = $this->_request->getParam('dir'); $count = $this->model->getCount(); $data = $this->model->getData($sort,$dir,0,$count); $this->_setListResponse($data); $this->_postJson(); } ... }Un appel Ajax est exactement comme pour tout appel battit su MVC de ZF une action pour contrôleur la demande invoquer le métier adéquat et retourner une vue dans ce cas en JSON
dans le cas d'un formulaire c'est la même chose le JS s'occupe de gérer tout l'IHM et communique en ajax avec le serveur il fait lui-même des vérification de saisie. pour il invoque la méthode pour poster les données en Ajax
le contrôleur ZF traite le formulaire comme n'importe quel contrôleur ZF le ferait avec filtrage vérification retour d'erreur et/ou action sur le modèle puis retourne une vue en JSON
Du coup plus besoin de vue en HTML c'est simple c'est rapide c'est évolutif.
effectivement ça sous exploite le capacité de ZF à générer l'IHM mais justement je trouvais que c'était le plus gros point faible de ZF. LA vue est trop souvent trop fortement couplée au contrôleur.
pour vous donner une idée d'une vue en ExtJS voici en entier celle qui gère l'affichage et la saisie des contacts dans mon applicationCode:
{ 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: controller.form }et pour le formulaire
Code:
{ baseCls: 'x-plain', url: controller.model.getUrl(), defaultType: 'textfield', monitorValid: true, reader: controller.model.getDataReader(), items: [ { fieldLabel: 'name', name: 'contact_name', anchor:'100%' // anchor width by percentage },{ fieldLabel: 'firstname', name: 'contact_firstname', anchor: '100%' // anchor width by percentage },{ fieldLabel: 'phone', name: 'contact_phone', anchor: '100%' // anchor width by percentage },{ fieldLabel: 'mail', name: 'contact_mail', vtype: 'email', anchor: '100%' // anchor width by percentage },{ fieldLabel: 'genre', xtype: 'combo', hiddenName: 'contact_genre', store: new Ext.data.SimpleStore({ fields: ['value', 'label'], data : controller.locale.genre }), displayField: 'label', valueField: 'value', allowBlank: false, //typeAhead: false, //editable:false, mode: 'local', forceSelection: true, triggerAction: 'all' },{ fieldLabel: 'groupe', xtype: 'combo', hiddenName: 'contact_group', store: controller.model.getGroupStore(), displayField: 'group_name', valueField: 'group_id', allowBlank: false, //typeAhead: false, //editable:false, mode: 'local', forceSelection: true, triggerAction: 'all' }], buttons: [ { text: controller.locale.save, formBind: true, type:'submit', name: 'contact_save', controller: controller, handler: function(){ this.disable(); //Ext.notif('save', 'click'); this.controller.saveData(); this.controller.on('saveFailed', this.enable, this); } }, { text: controller.locale.reset, //formBind: true, type:'reset', controller: controller, handler: function(){ this.disable(); //Ext.notif('reset', 'click'); this.controller.loadData(); this.enable(); } } ] }Voila on peu noter ici la concision pour définir un champs de saisie de type mail par exemple
Code:
{ fieldLabel: 'mail', name: 'contact_mail', vtype: 'email', anchor: '100%' // anchor width by percentage }cela suffit à définir un champ qui filtrera et gèrera seul la conformité de la saisie. pour la saisie de date de ma même manière on obtiendra un calendrier avec gestion des format etc.
A+JYT
Pourquoi garder l'architecture du Zend Framework MVC puisque ton javascript est MVC ?
En fin de compte tu n'as plus besoin des vues classique du ZF, et puis à quoi servent les contrôleurs censé interagir avec les vues et les modèles.
Dans cette architecture ou tu délaisses les traitements côté serveur au profit du client, et où tu communiques avec le serveur à partir de javascript, en fin de compte tu n'as plus besoin que du model du Zend Framework, non?
Hors ligne
Je ne délaisse pas les traitement ZF au profit de ExtJS
côté JS je ne mets pas de traitement métier dans la partie Modèle. le modèle dans ce cas est une proxy vers le modèle réel qui lui est sur le serveur.
le javascript ne gère donc que la logique applicative et non la logique métier.
utiliser MVC dans ce acs coté client permet de bien structurer son ode et bien définir l'API métier necessaire au fonctionnement. de plus le client est totalement indépendant de la technologie utilisée côté serveur (PHP JAVA C++ etc.)
la définition de la couche métier dans ce cas là fait l'interface entre l'appli client et l'API du serveur.
dans ce contexte pourquoi utiliser aussi MVC côté serveur. en fait on voit bien que une notion comme les webservices suffit. Alors pourquoi ?
c'est simplement que souvent on pense que MVC est destiné à gérer une application avec une IHM ce qui est faut. MVC est un concept qui s'applique dans de nombreux cas. et particulièrement au service. la vues est la couche présentation et non la couche ihm comme on a tendance à le croire. dans un service la présentation est la couche qui prépare et reçoit les données conformément à l'API du service.
avec ZF deux solution se présente utiliser la couche service de ZF mais il faut alors que toute l'API soit regroupé dans une classe qui est exposée comme service. cette implémentation de service est très pratique pour exposer un modèle circonscris et connexe. mais c'est une très forte contrainte pour exposer des services dis-connexes et au périmètre ouvert. l'autre solution consiste à utiliser la partie MVC de ZF et de faire des vue qui ne produisent plus du HTML mais formate les données comme attendu dans l'API.
Dans ce cas l'ajout ou l'évolution du périmètre est simple et souple. multiplier les ilôts disjoint dans le modèle exposé ne pose pas de difficulté. et surtout coté technique pure il n'est plus nécessaire de définir toute l'API pour que cela fonctionne. en effet ont bénéficie des capacités de ZF NVC à découvrir dynamiquement les composants et à dispatcher les appel dans des modules cohérents.
on gagne au passage un petit plus non négligeable on peut avoir un ou des contrôleurs qui permette de déployer le client.
maintenant sur le plan purement méthodologique utiliser MVC dans le cadre d'exposition d'un service est la possibilité des construire des services évoluer s'appuyant sur un modèle concis et cohérant
on a vu que la vue s'occupe alors de formater les échanges. le modèle lui définir le métier de du service. le contrôleur lui vas construire la logique de service.
on a alors dans l'architecture globale les couche suivantes
client.view => IHM
client.conrôleur => logique applicative
client.modèle => façade (proxy) du modèle de services
serveur.view => exposition des services
serveur.contrôleur => logique de service
serveur.modèle => logique métier
server.dao => logique d'accès aux donnée
server.datas => sources de données.
chaque couche est responsable de sa partie et de plus assure une indépendance des éléments.
par exemple je peux écrire un client en flex ExtJS, html+php c++ etc. sans changer de serveur
inversement je peux changer de techno serveur sans changer de client.
je peux changer de modèle sans changer le service ou changer de source sans changer de modèle. etc.
A+jyt
Hors ligne
Pour ma part j'utilise JQuery depuis peu et j'en suis assez contente
Hors ligne
sekaijin a écrit:
Je ne délaisse pas les traitement ZF au profit de ExtJS
côté JS je ne mets pas de traitement métier dans la partie Modèle. le modèle dans ce cas est une proxy vers le modèle réel qui lui est sur le serveur.
le javascript ne gère donc que la logique applicative et non la logique métier.
utiliser MVC dans ce acs coté client permet de bien structurer son ode et bien définir l'API métier necessaire au fonctionnement. de plus le client est totalement indépendant de la technologie utilisée côté serveur (PHP JAVA C++ etc.)
la définition de la couche métier dans ce cas là fait l'interface entre l'appli client et l'API du serveur.
dans ce contexte pourquoi utiliser aussi MVC côté serveur. en fait on voit bien que une notion comme les webservices suffit. Alors pourquoi ?
c'est simplement que souvent on pense que MVC est destiné à gérer une application avec une IHM ce qui est faut. MVC est un concept qui s'applique dans de nombreux cas. et particulièrement au service. la vues est la couche présentation et non la couche ihm comme on a tendance à le croire. dans un service la présentation est la couche qui prépare et reçoit les données conformément à l'API du service.
avec ZF deux solution se présente utiliser la couche service de ZF mais il faut alors que toute l'API soit regroupé dans une classe qui est exposée comme service. cette implémentation de service est très pratique pour exposer un modèle circonscris et connexe. mais c'est une très forte contrainte pour exposer des services dis-connexes et au périmètre ouvert. l'autre solution consiste à utiliser la partie MVC de ZF et de faire des vue qui ne produisent plus du HTML mais formate les données comme attendu dans l'API.
Dans ce cas l'ajout ou l'évolution du périmètre est simple et souple. multiplier les ilôts disjoint dans le modèle exposé ne pose pas de difficulté. et surtout coté technique pure il n'est plus nécessaire de définir toute l'API pour que cela fonctionne. en effet ont bénéficie des capacités de ZF NVC à découvrir dynamiquement les composants et à dispatcher les appel dans des modules cohérents.
on gagne au passage un petit plus non négligeable on peut avoir un ou des contrôleurs qui permette de déployer le client.
maintenant sur le plan purement méthodologique utiliser MVC dans le cadre d'exposition d'un service est la possibilité des construire des services évoluer s'appuyant sur un modèle concis et cohérant
on a vu que la vue s'occupe alors de formater les échanges. le modèle lui définir le métier de du service. le contrôleur lui vas construire la logique de service.
on a alors dans l'architecture globale les couche suivantes
client.view => IHM
client.conrôleur => logique applicative
client.modèle => façade (proxy) du modèle de services
serveur.view => exposition des services
serveur.contrôleur => logique de service
serveur.modèle => logique métier
server.dao => logique d'accès aux donnée
server.datas => sources de données.
chaque couche est responsable de sa partie et de plus assure une indépendance des éléments.
par exemple je peux écrire un client en flex ExtJS, html+php c++ etc. sans changer de serveur
inversement je peux changer de techno serveur sans changer de client.
je peux changer de modèle sans changer le service ou changer de source sans changer de modèle. etc.
A+jyt
Merci pour ta réponse complète. Il faut que je revois tout ça à tête reposé. J'avoue avoir un peu de mal face à autant de séparation de couches, c'est probablement du à mon inexpérience dans les autres "types" d'applications.
En attendant, pour mon utilisation, je reste bluffé de la simplicité de JQuery à manipuler le DOM. L'enrichissement de interactivité est aussi un plus indéniable à condition d'être utilisé prudemment.
Hors ligne