Sujet : Amélioration du dispatcher du controlleur frontal

Bonsoir,

Voilà, l'idée principale est de pouvoir répartir les requêtes de type XHR (ou AJAX) vers une action spécifique.
Voir même de désactiver les rendus / vue & layout.

Exemple:
Requête HTTP : http://host/controller/action/ -> controllerController.php actionAction()
Requête HTTP XHR : http://host/controller/action/ -> controllerController.php actionActionXhr()

L'idée est de pouvoir interagir dans un contexte différent.
Pour les applications extjs, etc.

Vos avis ?

2

Re : Amélioration du dispatcher du controlleur frontal

Hey smile,

J'avais prévenu que j'étais plus actif par mail que sur le forum, la preuve wink.

J'étais parti sur l'idée suivante : on a le routage qui est fait et le dispatche appelle ce qu'on veut (classe, méthode, fonction, closure, flux … ce qu'on veut). Si on prend ton exemple, on va appeler une classe et une méthode.
Une fois dans notre classe, on peut connaître la méthode de requête (selon la terminologie HTTP) : $this->request->getMethod() // GET, POST, PUT, DELETE, TRACE etc. Mais de manière moins standard (c'est en cours de standardisation), la majorité des bibliothèques Javascript envoie l'en-tête HTTP X-Requested-With: XMLHttpRequest quand on envoie une requête XHR. Dans ce cas, on peut imaginer une autre méthode du genre $this->request->isAjax().

Ça nous offre deux possibilités.
La première, la plus triviale, c'est de traiter la méthode de requête dans une action commune :

class FooController {

    public function BarAction ( … ) {

        if($this->request->isAsynchronous())
            …

        switch($this->request->getMethod()) {

            case 'get':
                …
        }
    }
}

C'est une première façon de faire.

Mais comme dans Hoa, on peut tout configurer à souhait, grâce à Hoa_Core_Parameterizable et le zFormat, on va pouvoir dire au routeur qu'il peut rediriger sur : BarAction, BarActionAsync, BarActionGet, BarActionGetAsync etc.
On exprimerait ça sous la forme suivante :

'action.synchronous' => '(:action:U:)Action(:method:U:)'

pour les cas BarActionGet, BarActionPost etc., et :

'action.asynchronous' => '(:action:U:)Action(:method:U:)Async'

pour les cas avec XHR.

Je pensais partir sur la première idée au début mais ta réflexion m'a donné l'idée de la seconde. Et c'est même une très bonne idée. Je code ça de suite (je comptais le faire demain, mais l'idée est top et je veux tester).
Le nouveau Hoa_Controller, avec Hoa_Http, sera bientôt dans le trunk.

« Un handicap est le résultat d'une rencontre entre une déficience ou différence et une incapacité de la société à répondre à celle-ci. »

Re : Amélioration du dispatcher du controlleur frontal

Merci Hywan, c'est trop classe !

Je savais bien que tu trouverai un truc autour de XMLHttpRequest.

J'ai pas voulu par mail car sinon c'est un peu comme un "hide-communauty". wink

Des idées comme celle-ci pour dynamiser le framework, répondre aux (vrais ?) besoins et se démarquer, j'en ai pas mal ^^

Re : Amélioration du dispatcher du controlleur frontal

Ceci-dit, il faudra bien m'expliquer le routeur car je veux le dynamiser pour Wasium et pouvoir le modéliser pour le mettre en BDD. Si d'ailleurs tu as un ou deux tuyaux, là, je suis présent par mail tongue

5

Re : Amélioration du dispatcher du controlleur frontal

Le routeur est maintenant uniquement basé sur les expressions régulières. Il faut nommer toutes les parties que l'on souhaite capturer. Par exemple :

^foo/(?<bar>[^\.]+)\.html$

Et dans notre action (une méthode, une closure etc., peu importe), bar va être associé au paramètre $bar. Exemple :

class GordonController {

    public function FreemanAction ( $bar ) {

        var_dump($bar);
    }
}

Si on appelle la page avec /foo/the-cake-is-a-lie.html, alors notre action va recevoir the-cake-is-a-lie en paramètre de $bar. L'idée n'est pas de moi mais c'est astucieux (et facile à coder en plus …).

Si tu as d'autres idées comme celle de l'asynchrone, donnes les moi. Sans que tu le saches forcément, celle que tu viens de soumettre s'inscrit dans un processus de plus haute abstraction d'un couple dispatcher/router.

Enfin, les règles de routage pourront facilement s'enregistrer en base de données, où dans un fichier JSON, XML, YAML, INI … ce que tu veux.

« Un handicap est le résultat d'une rencontre entre une déficience ou différence et une incapacité de la société à répondre à celle-ci. »

6

Re : Amélioration du dispatcher du controlleur frontal

Un petit exemple de configuration externe pour le routeur au format JSON :

{
    /**
     * Keywords.
     */
    "keywords": {},

    /**
     * Parameters.
     */
    "parameters": {
        "base"    : "/",
        "rewrited": false,
        "rules"   : [
            ["^foo/(?<act>.{2})(?<foo>.)/?$", "gordon", "freeman"]
        ]
    }
}

Déjà, oui, tu ne rêves pas, tu as bien des commentaires dans le JSON. Hoa_Json le supporte.
Ensuite, ce qui nous intéresse, c'est la partie rules. Tu remarques qu'on démarre une liste/tableau indexé "rules": [, mais on peut très bien démarrer un tableau associatif et nommer les règles. Ainsi on aurait :

        "rules"   : {
            "simple": ["^foo/(?<act>.{2})(?<foo>.)/?$", "gordon", "freeman"],
            "hard"  : […]
        }

Note qu'on travaille avec au minimum un 3-uplet : [pattern, controller, action]. Mais on peut avoir un 3-uplet non-continue : [pattern, null, action] (si on veut exécuter une fonction ou une closure, ou [pattern, stream, null], [pattern, stream, action] pour des flux etc. Et on peut également avoir un 4-uplet : [pattern, controller, action, {extra}] ou [pattern, controller, action, [extra]].
Bref, je ne détaille pas tout ici, ce sera fait dans la documentation, mais c'est pour te donner une idée.

« Un handicap est le résultat d'une rencontre entre une déficience ou différence et une incapacité de la société à répondre à celle-ci. »