Hey ,

Comme promis, je réponds à vos questions.
Pendant longtemps, ce projet de Hoa\Application m'a trotté dans la tête, je dois l'avouer. Mais comme Hoa\Controller est devenu très simple et plutôt bien découplé, j'ai décidé de l'arrêter. Toutefois, vos interrogations me refont réfléchir. Je détaille vos suggestions.

Malian :

Merci merci . Ça fait plaisir !

Malian :

Je ne peux pas te contredire en partie.
Hoa est effectivement un ensemble de bibliothèques harmonisées comme on le sait tous. Mais la présence de la partie Data « transforme » les bibliothèques en partie en framework car elle permet une forme d'automatisation et externalise certaines choses comme les configurations. On va voir dans quelle mesure.

Malian :

Oui exactement. C'est l'objectif et une des conséquences de la modularité, à savoir imbriquer nos briques logiciels.

Malian :

Là est toute la question. Sauf que ce composant Zend_Application n'offre pas toute la modularité que je propose avec Hoa. En fait, on va se restreindre. Zend ne fait que de l'HTML et ne vise que du Web. Hoa vise toutes les plateformes et pas seulement du Web. C'est pour ça qu'on doit préciser l'interpréteur de XYL par exemple.
Mais j'ai la solution à ton problème je pense .

Pour donner un exemple des configurations externalisées, les règles du routeur peuvent être ceci (dans Data/Etc/Configuration/HoaControllerRouter.json) :

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

    /**
     * Parameters.
     */
    "parameters": {
        "base"    : "/",
        "rewrited": false,
        "rules"   : [
           ["h", "p(?<id>\d+)-(?<title>.*)", "index", "picture"],
           ["g", "(?<all>.*)", "index", index"]
        ]
    }
}

Et c'est tout bon (il faut re-générer les caches, opérations cassées dans la 1.0.0b1 volontairement, ça va revenir). Tu réduis donc ton index.php à :

<?php

require __DIR__ . '/../../Framework/Core/Core.php';

from('Hoa')
-> import('Controller.Dispatcher.Basic')
-> import('Controller.Router');

$router     = new Hoa\Controller\Router();
$dispatcher = new Hoa\Controller\Dispatcher\Basic();
$dispatcher->dispatch($router);

Mais je comprends que ça ne résoud pas le problème que tu as. Tu veux aller plus loin.

Soit.

Facile. Pourquoi ne pas faire un module Hoathis ? Je viens de t'en faire un pour que tu vois. Dans Framework/Module/, tu vas crééer Application/Application.php pour avoir ceci :

Framework/
|-- Module/
|   |-- Application/
|   |   |-- Application.php

Le contenu de Application.php sera le suivant (par exemple) :

<?php

namespace {

from('Hoa')
-> import('Controller.Dispatcher.Basic')
-> import('Controller.Router')
-> import('Xyl.~')
-> import('File.Read')
-> import('Http.Response');

}

namespace Hoathis\Application {

class Application {

    protected $_interpreter = null;
    protected $_router      = null;
    protected $_dispatcher  = null;

    public function __construct ( $interpreter = 'html', $rewrited = false ) {

        $this->_interpreter = ucfirst(strtolower($interpreter));
        $this->_router      = new \Hoa\Controller\Router();
        $this->_router->setParameter('rewrited', $rewrited);
        $this->_dispatcher  = new \Hoa\Controller\Dispatcher\Basic();

        return;
    }

    public function dispatch ( ) {

        return $this->_dispatcher->dispatch(
            $this->_router,
            new \Hoa\Xyl(
                new \Hoa\File\Read('hoa://Application/View/Main.xyl'),
                new \Hoa\Http\Response(),
                dnew('Hoa\Xyl\Interpreter\\' . $this->_interpreter)
            )
        );
    }
}

}

Très simple pour l'instant ! Notons dnew(). Modifions maintenant ton Application/Public/index.php, il aura cette tête là :

<?php

require __DIR__ . '/../../Framework/Core/Core.php';

from('Hoathis')
-> import('Application.~');

$application = new Hoathis\Application();
$application->dispatch();

Et voilà le travail. En modifiant les configurations de \Hoa\Controller\Router, on pourra modifier le comportement de \Hoathis\Application facilement, et on peut même lui créer des configurations (pour externaliser l'interpréteur par exemple) ! Tu vois l'idée ? Et là, tu auras l'équivalent de Zend_Application (ou un début).

Ecureuil Virtuel :

Je ne sais pas comment Malian l'a perçu, mais je l'aurais presque mal pris . Il utilise Hoa depuis moins longtemps que toi et c'est normal qu'il n'en sache pas autant que toi . Et tu l'as bien souligné :

Ça n'arrange rien !

Je tiens à rectifier certaines choses que tu as dites par contre (rien de méchant, mais il faut tenir un discours clair ) :

Le dossier Application, tout comme le dossier Data, et même Framework, sont des noms conventionnels. Rien ne t'oblige à les appeler comme ça ! Grâce à hoa://, tu peux y accéder dans ton code en conservant une convention de nommage des dossiers, mais comme ce sont des liens symboliques, tu peux les nommer comme tu veux. Donc le pluriel sur Application ou Applications ne changera rien. Tu avais utilisé cette convention par le passé car tu voulais gérer plusieurs applications. C'était une excellente idée, mais rien ne t'oblige à toutes les mettre dans le même dossier, tu me suis ? Tu peux très bien créer un composant hoa://Applications/App1 ou hoa://Applications/App2 etc., ça ne changera pas grand chose, tu t'organises comme tu veux, du moment que c'est clair pour toi .

Pareil pour le dossier Public, il ne se trouve pas forcément dans Application et ne s'appelle pas forcément Public. Ce serait un peu étrange, je te l'accorde, mais rien ne t'y oblige ! Ce ne sont que des conventions, mais en aucun cas Hoa impose une quelconque architecture (on est dans des bibliothèques que diable ).

En revanche, je te rejoins à propos du rendu de la vue. Le rendu n'est pas automatique, mais peut-être que je pourrais ajouter ça à \Hoa\Controller\Dispatcher\Basic, ce n'est pas une si mauvaise idée. En revanche, pour l'utilisation dynamique de définitions XYL, je ne peux pas automatiser car ce n'est pas quelque chose que l'on ferait systématiquement. On peut très utiliser des overlay ou ne rien faire du tout. On peut avoir des actions silencieuses qui appellent d'autres actions.

Ecureuil Virtuel :

Très très dur, faut pas exagérer .

MaitrePylos :

Je l'aime bien aussi tiens . C'est un peu mon objectif dans l'idée, bien trouvé ! Je pense que c'est ce qu'a voulu exprimer Ecureuil Virtuel également.

Malian, le retour :

Pourquoi pas, mais ce serait en module Hoathis. Vous pouvez même être les mainteneurs de cette bibliothèques et elle pourrait être officielle (c'est à dire livrée conjointement avec Hoa).

Malian :

J'ai besoin de ce genre de retour aussi pour réussir à me situer. On m'a reproché ces derniers temps d'être trop en décalage par rapport à ce qui existe. C'est positif et négatif à la fois. Il faut réussir à assurer une transition et rassurer les nouveaux venus qui utilisent déjà Zend Framework ou Symfony. Donc tes remarques m'intéressent.

Malian :

C'est exact, sauf qu'on a aussi Data dans Hoa, c'est une petite subtilité. Mais Data peut être rangé dans Application …

Malian :

Oui, on peut faire ce que tu proposes dans ton architecture avec Hoa. Il faut modifier le paramètre synchronous.file (ou asynchronous.file) de \Hoa\Controller\Dispatcher. Tu peux donner comme valeur

hoa://Application/modules/(:controller:l:)/controllers/…

et le tour est joué (je reprends les mêmes termes que tu as donné en exemple). Et pour arriver à ce résultat, ça se fait en deux coups de cuillière à pot !

Malian :

Sauf que tu peux développer tes bibliothèques Hoathis à deux niveaux : dans Framework ou dans Data. Si tu le fais dans Framework, toutes tes applications en bénéficieront, si tu le fais dans Data, seule ton application courante en bénéficiera. Tu vois l'idée ? C'est pour ça que je te l'ai mis dans Framework/Module/, comme ça tu n'auras plus à la développer. Est-ce un moyen terme ?
De plus, si ça passe en bibliothèque Hoathis standard, tu n'auras même plus à la développer. Mais je pense que les besoins de chacun sont différents, ça mérite donc réflexion .

Malian :

Pour la beauté du geste répondrai que Hoa n'est ni Zend Framework ni Symfony et que je n'ai pas l'intention de les copier parce qu'ils sont leaders. Mon but n'était pas de faire du full-stack au début mais de permettre d'en faire. C'est à ça que Hoathis peut être utile également.

Malian :

Tu peux détailler s'il te plaît ?

Malian :

Tu as rencontré des difficultés sur quelle partie exactement ?

Malian :

Je n'ose pas relire ma réponse …

Malian :

Je supporte tout à fait la comparaison tant que c'est utile et constructif. Je ne vois pas pourquoi Zend Framework ou Symfony seraient des concurrents. Jelix ne l'est pas du tout et on échange souvent nos idées, problèmes, solutions etc. Et je ne joue pas dans la même catégorie qu'eux. Ils sont orientés full-stack, je suis orienté bibliothèques.

Ecureuil Virtuel :

Peut-être qu'elle est impressionnante mais elle se justifie. Et il faut que Hoa puisse le faire. Si mes principes sont bons, ça devrait être envisageable et faisable. Si c'est le cas, j'ai gagné et on a un truc encore plus modulaire et universel (abstrait quoi). C'est l'objectif .
Mais j'avoue que ça me fait peur aussi .

Maitre Pylos, le retour :

Tous les avis comptes. Et j'ai reçu le message. Est-ce que ma solution te convient également ?