Zend FR

Bon, j'ai trouvé une solution, peut être pas belle mais ça fonctionne, j'ai développé un plugin et dans ce dernier, je teste, si l'action que je veux faire nécéssite une inclusion de header et du footer, ou est ce que je veux que juste le formulaire s'affiche.
Si vous avez une meilleur solution, elle est la bienvenue.

Cordialement

Bonjour Fred, Verboz,

Idem, je vais essayer de décrire ma méthode, mais ça n'est pas facile non plus. Par rapport à la version de Fred, c'est beaucoup plus en javascript et beaucoup moins en PHP...

Quand j'envoie une page dans le navigateur, il me faut 2 templates (j'utilise smarty, mais ça ne change rien au principe) :
- le HTML de ma page
- un fichier JS qui est inséré dans le header de ma page

Le fichier JS indique chacun des éléments dynamiques de ma page (bouton de submit, bouton d'activation, onchange sur un formulaire, n'importe quoi qui provoque un évenement javascript). Ce fichier JS dit pour chaque évènement qui nous intéresse :
"appelle en ajax le service qui est à l'URL http://monsite/service/MaCommande"

Pour chaque URL du type .../service/MaCommande, j'appelle un controlleur particulier qui récupère les données envoyées en POST et appelle une fonction "execute(params)" de la classe Kitpages_Command_xxx_MaCommande.

La commande traite les données envoyées. Eventuellement elle appelle une autre action pour récupérer un code HTML. La commande renvoie un tableau avec : un code retour ("OK", "FAIL",...) et un contenu (un tableau associatif ou une string)
Le ServiceController encode en JSON la réponse de la commande et renvoie le tout au navigateur.

La réponse du service est captée par le Javascript de la page. Suivant le code retour, le javascript peut effectuer l'action qu'il souhaite (notamment il raffraichir une zone avec le contenu reçu depuis la commande...)

Cette architecture est ce que j'appelle un MVC coté client : chaque composant actif de la page contient un modèle, une vue et un controlleur. C'est le principe des interfaces lourdes (swing, swt,...).

J'ai un exemple qui tourne en prod : http://www.euromapping.com (faites pas gaffe au graphisme, il devrait changer d'ici 15 jours...). Le MVC client est assuré en Javascript avec le fichier Kitpages.js (j'adore javascript... j'y peux rien ça me rappelle les délires de perl...)

Hum... désolé si c'est pas super clair, mais c'est pas non plus super facile à expliquer...

A+, Philippe

J'utilise DOJO pour cette partie javascript "dynamique" et son dojo.io.bind

ça donne ça :

function commun_onPostFormulaire(form, urlAction)
{
    dojo.io.bind({
        url: urlAction,
           method: "POST",
           load: commun_traiterFormulaire,
           error: commun_traiterErreurs,
           formNode: dojo.byId(form)
    });
}

Cette fonction est appelée lors de la soumission du formulaire avec l'id du formulaire (form) et une url pour l'action du type /module/contrôleur/action/

Ensuite j'ai 2 fonctions qui permettent de traiter le formulaire sans erreur et une pour traiter les erreurs.

function commun_traiterFormulaire(type, data, evt) {
    commun_cacherAttente();
    
    var donnees = data;
    commun_traiterJSON(donnees);
}

function commun_traiterErreurs(type, message) {
    commun_afficherErreurDialog("Erreur inconnue (" + message + ")");
}

La fonction commun_traiterErreurs fait appel à une fonction qui permet d'afficher une boite de  dialogue avec l'erreur javascript.

Les données du formulaire sont traitées dans la fonction commun_traiterJSON qui s'occupe de traiter les erreurs fonctionnelles et de faire les redirections (elle est un peu compliquée) :

function commun_traiterJSON(data) {
    
    libFloatErreur = "";
    var json = dojo.json.evalJson(data);
    if ( json.etat == "OK" ) {
        if ( json.redirect ) {
            // parcours des redirections éventuelles
            for (var i in json.redirect) {
                redirection = json.redirect[i];
                commun_IHMRedirect(redirection.zone, redirection.url);
            }
        }
        
        if ( json.js ) {
            // parcours des js éventuelles
            for (var i in json.js) {
                eval(json.js[i]);
            }
        }
    } else {
        dialogErreur = false;
        dialogTexte = "";
        // parcours des erreurs
        if ( json.erreurs ) {
            for (var i = 0; i < json.erreurs.length; i++) {
    
                type   = json.erreurs[i].type;
                champErreur   = json.erreurs[i].champ;
                libelleErreur = json.erreurs[i].libelle;
                
                if (type == "CHAMP") {
                    libFloatErreur = libFloatErreur + " - " + libelleErreur + "<br>";
                    commun_afficherErreurChamp(champErreur + "_label", libelleErreur);
                } else if (type == "ONGLET") {
                    commun_afficherErreurOnglet(champErreur);
                } else if (type == "DIV") {
                    libFloatErreur = libFloatErreur + " - " + libelleErreur + "<br>";
                    commun_afficherErreurDIV(champErreur, libelleErreur);
                } else if (type == "DIALOG") {
                    libFloatErreur = libFloatErreur + " - " + libelleErreur + "<br>";
                    dialogErreur = true;
                    dialogTexte += '<li>' + libelleErreur + '</li>';
                }
            }
            
            if ( dialogErreur ) {
                commun_afficherErreurDialog(dialogTexte);
            }
        }
        else if ( json.js ) {
            // parcours des js éventuelles
            for (var i in json.js) {
                eval(json.js[i]);
            }
        }
         else {
             libFloatErreur = libFloatErreur + " - " + json + "<br>";
            commun_afficherErreurDialog("Erreur inconnue : " + json);
        }
        
        // Affichage du div comportant les erreurs
        divPaneErreurs = dojo.byId("divPaneErreurs");
        if(divPaneErreurs) {
            divPaneErreurs.innerHTML = 
                                    '<img src="/images/icons/ico_warning.gif" '
                                    + 'align="absmiddle" border="0" hspace="2" name="icoWarningDiv">'
                                    + "<font color='red'><b>"+json.action + "</b></font><hr>"+ libFloatErreur;
            
            if(! dojo.widget.byId("paneErreurs").isShowing() && !dialogErreur) {
                dojo.widget.byId("paneErreurs").show();
            }
        }
    }
}

Voila, en gros, dans le contrôleur, on traite les données reçues et on encode en json un tableau associatif qui est de la forme :
$retour["etat"] qui prend les valeurs OK ou KO
$retour["js"] qui est un tableau de commande javascript
$retour["redirect"] qui est un tableau associatif sous la forme $retour["redirect"][x]["zone"] pour l'id du div à mettre à jour et $retour["redirect"][x]["url"] pour l'url de mise à jour
$retour["erreurs"] qui est un tableau des erreurs fonctionnelles (essentiellement) qui peuvent être de type différent genre une erreur sur un champ du formulaire, une erreur de type dialog qui affichera une boite de dialogue, ...

Voila, si vous avez des questions ou des remarques, je suis preneur. Je pense que la fonction commun_traiterJSON peut être améliorée et optimisée.

Salut,
Merci les gars pour toutes vos réponses, en fait je connaissais cette stratégie d'échange de donnée en Json, mais bon, je voulais pas toucher à mon application trop, pour que le jour où je décide d'enlever l'Ajax de mon application j'aurais pas bcp de chose à modifier (juste l'appel change). Bref, j'utilise Json juste pour encoder des objects que je retourne au client car je vois pas l'intérêt d'encoder du HTML pour le retourner au client.
Si je me trompe, n'hésitez pas, je ne suis pas une référence dans Ajax, peut être que j'ai mal compris.

Bon voilà ce que je fais:

require_once 'Zend/Controller/Plugin/Abstract.php';

class My_Controller_Plugin_AutoView extends Zend_Controller_Plugin_Abstract {

    private $_lastAction;

    public function __construct() {
        $view = new Zend_View;
        $view->setScriptPath(APP_ROOT.'/views/');
        Zend_Registry::set('view', $view);
    }

    public function preDispatch($action) {
        $this->_lastAction = clone($action);
        return $action;
    }
    public function postDispatch($action) {
        
    }

    public function dispatchLoopShutdown() {
        if($this->_lastAction->getControllerName()!="authent")//Tout se passe ici <========== 1
        {
            require_once(dirname(__FILE__)."/template/header.phtml");
                     
        }
    }
}

Dans la partie 1, on pourrais penser à un tableau et vérifier si le nom du controlleur existe dans le tablau ou non, si oui alors, on inclus le template(header+footer+autre chose) sinon, on laisse vide et de cette façon on auras que le code de la vue qui est retourné.

Je vois que cette solution est meilleur, pas la peine d'encoder et de décoder et on pourrais facilement enlever le fonctionnement Ajax (Cas des navigateurs sur les portables,....)

Cordialement

Le pb d'ajax est le référencement et le debugage, c'est quelque de nouveau et qui n'est pas pris en considération par les moteurs de recherche, donc ce n'est pas un pb qui concerne la méthode de Fred. Autres limites d'Ajax: B2B, les bouttons de navigation (reglé avec jquery en utilisant le plugin Hiajax). Donc personnellement, j'utilise ajax mais pas dans la navigation (exemple, soumission d'un formulaire, lightbox, vérification, mise à jour dans la base de données, des trucs de ce genre).

Cordialement

Bonjour les gars,

En fait je développe uniquement des applications de gestion, intranets. Mes obligations sont surtout la rapidité d'éxecution, d'affichage et une interface puissante. Moins les sites sont référencés, mieux je me porte (heureux homme, non ? , et en plus je ne me soucie de faire tourner les applis uniquement que sur un, voire deux navigateurs...). Ce sont des applications que les utilisateurs manipulent 8 heures par jour...

Mais effectivement pour le référencement, je n'ai qu'une url. Pour ce problème il faut demander à Philippe, qui lui fait des sites ouverts sur le web et utilise Ajax, je ne sais pas comment il se débrouille.

Je crois qu'il faut trouver un bon compromis entre rapidité d'affichage, interface puissante et puis...le référencement . Ce pourrait être une discussion à lancer sur le site.

Quant au debuggage, un jour est apparu firebug, extension firefox, c'est magique ! Point  d'arrêt, suivi de variables, pas à pas etc... pour le javascript, unDOM inspector, un truc pour les css, les temps de réponse...Nickel, même avec des bibliothèques genre prototype.js.

A+

Fred

Le problème avec Ajax, c'est que dès qu'on met le doigt dedans, on est tenté de tout coder à l'intérieur d'une seule et unique page en ne rafraichissant que des zones de pages. Intellectuellement c'est hyper satisfaisant, on peut avoir un code très propre et très homogène. Dans ce cas, un robot d'indexation ne comprend rien et ne voit que la première page.

Là dessus, il n'y a pas de solution magique pour un site public : il faut limiter l'ajax à des éléments dynamiques qui de toute façon n'auraient pas été indexés : formulaire d'indentification, ajout au panier, espace client,...

Par contre si on veut qu'un catalogue de produit soit indexable, pas le choix, il faut oublier javascript et faire des bons liens bien classiques <a href...>.

En ajax, c'est clairement plus confortable de coder une interface d'admin ou un intranet, on peut oublier google très sereinement (Ô bonheur...).

A+, Philippe

Bonjour,

Juste par curiosité,

comment gérez-vous le cas où le javascript est désactivé sur le poste utilisateur ? Par exemple Philippe, est-ce que tu prévois une solution de rechange pour le formulaire d'indentification ou l'ajout au panier ?

Bonne journée,

Fred

Exactement pareil que philippe. En revanche j'aimerais bien connaitre les stats sur les personnes qui désactive js mais à mon avis ca doit pas dépasser 0.1 %. Puis désactiver js c'est complétement contradictoire avec le web, c'est comme si je désactivais les vitres electriques et la clim de ma bagnole ...