Zend FR

Consultez la FAQ sur le ZF avant de poster une question

Vous n'êtes pas identifié.

#51 07-11-2007 14:19:30

Moimeme
Membre
Date d'inscription: 19-04-2007
Messages: 120

Re: Toolkit Javascript

A mon avis le validateur W3C il doit clignoter de partout ...

Hors ligne

 

#52 07-11-2007 14:46:04

TiTerm
Membre
Date d'inscription: 01-07-2007
Messages: 175

Re: Toolkit Javascript

Et quand a utiliser une extention type TIDY, ca doit pas être gagné non plus hmm

Hors ligne

 

#53 07-11-2007 20:06:39

sekaijin
Membre
Date d'inscription: 17-08-2007
Messages: 1137

Re: Toolkit Javascript

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

 

#54 07-11-2007 20:23:26

TiTerm
Membre
Date d'inscription: 01-07-2007
Messages: 175

Re: Toolkit Javascript

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

 

#55 07-11-2007 20:56:58

sekaijin
Membre
Date d'inscription: 17-08-2007
Messages: 1137

Re: Toolkit Javascript

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

 

#56 08-11-2007 08:32:35

Moimeme
Membre
Date d'inscription: 19-04-2007
Messages: 120

Re: Toolkit Javascript

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

 

#57 08-11-2007 09:04:19

sekaijin
Membre
Date d'inscription: 17-08-2007
Messages: 1137

Re: Toolkit Javascript

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

 

#58 08-11-2007 09:31:17

Moimeme
Membre
Date d'inscription: 19-04-2007
Messages: 120

Re: Toolkit Javascript

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

 

#59 08-11-2007 19:03:33

Moimeme
Membre
Date d'inscription: 19-04-2007
Messages: 120

Re: Toolkit Javascript

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

 

#60 08-11-2007 20:19:22

sekaijin
Membre
Date d'inscription: 17-08-2007
Messages: 1137

Re: Toolkit Javascript

ne les ajouter c'est simple faire un validateur qui les accepte ça c'est pas gagné
sinon il te suffit de faire ça

Code:

<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

 

#61 19-11-2007 11:54:47

Damien
Membre
Lieu: Tassin la Demi Lune
Date d'inscription: 22-03-2007
Messages: 88

Re: Toolkit Javascript

Juste pour info, Dojo est sorti en version 1.0.0 depuis déjà quelques temps smile

Le système des dijit est sympa et surtout on peut en ajouter assez facilement.

Hors ligne

 

#62 19-11-2007 13:11:39

xender
Membre
Date d'inscription: 04-11-2007
Messages: 23

Re: Toolkit Javascript

Jquery pour moi aussi

Hors ligne

 

#63 16-06-2009 16:00:32

yo49
Nouveau membre
Date d'inscription: 16-06-2009
Messages: 8

Re: Toolkit Javascript

Jquery (PRATIQUE et BEAU)

Hors ligne

 

#64 16-06-2009 21:05:10

sekaijin
Membre
Date d'inscription: 17-08-2007
Messages: 1137

Re: Toolkit Javascript

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

 

#65 16-06-2009 22:17:26

Delprog
Administrateur
Date d'inscription: 29-09-2008
Messages: 670

Re: Toolkit Javascript

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.


http://www.anonymation.com/ - anonymation - Studio de création.
http://code.anonymation.com/ - anonymation - blog - développement et architecture web

Hors ligne

 

#66 17-06-2009 08:06:21

nORKy
Membre
Date d'inscription: 06-03-2008
Messages: 1098

Re: Toolkit Javascript

JQuery !!


----
Gruiiik !

Hors ligne

 

#67 17-06-2009 10:26:20

Vincent
Administrateur
Date d'inscription: 19-09-2008
Messages: 510

Re: Toolkit Javascript

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.


aka miboo

Hors ligne

 

#68 17-06-2009 11:07:09

sekaijin
Membre
Date d'inscription: 17-08-2007
Messages: 1137

Re: Toolkit Javascript

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

Code:

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 Ajax

Code:

<?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

Code:

{
    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

Dernière modification par sekaijin (17-06-2009 11:41:03)

Hors ligne

 

#69 17-06-2009 12:54:13

Delprog
Administrateur
Date d'inscription: 29-09-2008
Messages: 670

Re: Toolkit Javascript

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 ? smile

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.


http://www.anonymation.com/ - anonymation - Studio de création.
http://code.anonymation.com/ - anonymation - blog - développement et architecture web

Hors ligne

 

#70 17-06-2009 14:09:12

sekaijin
Membre
Date d'inscription: 17-08-2007
Messages: 1137

Re: Toolkit Javascript

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 ? smile

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

Code:

<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

Code:

<?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

Code:

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

Code:

        <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

Code:

        <div id="data">
        </div>
        <script type="text/javascript" src="<?php echo $this->baseUrl; ?>/public/scripts/grid.js"></script>

et

Code:

/*
 * 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.

Code:

<?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

 

#71 18-06-2009 14:20:49

matdev
Membre
Date d'inscription: 31-03-2009
Messages: 172

Re: Toolkit Javascript

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

 

#72 02-07-2009 17:07:59

Vincent
Administrateur
Date d'inscription: 19-09-2008
Messages: 510

Re: Toolkit Javascript

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 javascript

Code:

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 Ajax

Code:

<?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

Code:

{
    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?


aka miboo

Hors ligne

 

#73 04-07-2009 13:35:57

sekaijin
Membre
Date d'inscription: 17-08-2007
Messages: 1137

Re: Toolkit Javascript

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

 

#74 08-07-2009 08:37:39

aelyta1
Membre
Lieu: Rouen
Date d'inscription: 29-06-2009
Messages: 98

Re: Toolkit Javascript

Pour ma part j'utilise JQuery depuis peu et j'en suis assez contente


veni, vidi, riendi
Vive les lapins-antilopes !

Hors ligne

 

#75 08-07-2009 09:58:19

Vincent
Administrateur
Date d'inscription: 19-09-2008
Messages: 510

Re: Toolkit Javascript

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.


aka miboo

Hors ligne

 

Pied de page des forums

Propulsé par PunBB
© Copyright 2002–2005 Rickard Andersson
Traduction par punbb.fr

Graphisme réalisé par l'agence Rodolphe Eveilleau
Développement par Kitpages