avoir une sortie en "live" dans la console quand on utilise cmdline

euh... echo "pouet"; ne suffit pas ?

si si :)

Je ré-ouvre le ticket. On pourrait avoir un jResponseCmdline, identique que jResponseText mais sans l'envoi d'entete ou autre, et avec une méthode type setContent qui ne ferais qu'un echo (avec la possibilité pourquoi pas de "bufferiser")... Au moins ça ne casse pas le principe de jelix.

J'allais rebondir sur la fermeture de ce ticket un peu précipité. Je préfère moi aussi voir l'ajout d'une réponse adaptée pour que ça soit plus propre

Replying to laurentj:

Je ré-ouvre le ticket. On pourrait avoir un jResponseCmdline, identique que jResponseText mais sans l'envoi d'entete ou autre, et avec une méthode type setContent qui ne ferais qu'un echo (avec la possibilité pourquoi pas de "bufferiser")... Au moins ça ne casse pas le principe de jelix.

Il serait pas mal aussi de gérer le code de retour de la ligne de commande, donné grâce a la commande exit.

Voila une tentative de proposition.

Il est possible definir le code de retour, et le code de retour est automatiquement a 1 pour une erreur non interceptee.

Cela implique quelques modifs dans le jCoordinator...

J'ai laisse aussi la possiblite de bufferiser avec un parametre booleen pour setContent.

En guise de test, j'ai un peu modifie le controleur de ligne de commande de junittest qui utilise maintenant cette reponse. Cette nouvelle reponse devient d'ailleur la reponse par defaut des requetes en ligne de commande.

Je n'aime pas trop ce hack sur jCoordinator. Je pense qu'il est préférable de faire un coordinateur spécifique pour les lignes de commande, héritant de jCoordinator.

Et on pourrait simplifier le code. Par exemple, pourquoi renvoyer le code status en sortie d'output() ? Je pense qu'on pourrait dans Output tester le code exist_status, et selon sa valeur renvoyé true ou false. Donc le test dans le coordinateur serait inutile. Et à la fin du process, on a juste à faire un exit($this->response->exitStatus). Donc cela reviendrai à avoir

class jCmdlineCoordinator extends jCoordinator {
   public function process ($request){
     parent::process($request);
      exit($this->response->exitStatus ); 
   }
}

Bien sûr, il faut rajouter cette propriété exitStatus... (ou un getExitStatus). D'ailleurs, je préfère qu'on l'appelle exitCode..

Je n'avais pas envisagé de faire un coordinateur spécifique. C'est vrai que sa simplifie pas mal la gestion du code de retour.

Je vais m'occuper de ça.

Merci

J'ai mis a jour le patch. Plus de "bidouilles" dans le jCoordinator. Je pense que c'est plus propre maintenant.

C'est effectivement plus propre. Quelques petits trucs cependant :

Index: testapp/scripts/cmdline.php
 
-$jelix = new jCoordinator($config_file);
+$jelix = new jCmdlineCoordinator($config_file);

Ok, mais il faut faire un include du fichier de jCmdlineCoordinator. Il ne faut pas l'inclure dans init.php puisque c'est inutile la plupart du temps. Donc le patch sur init.php est à annuler.

Même remarque sur testapp/scripts/tests.php, et lib/jelix-scripts/templates/scripts/cmdline.php.tpl

lib/jelix-modules/junittests/controllers/default.cmdline.php

     protected function _prepareResponse(){
-        $rep = $this->getResponse();
+        $rep = $this->getResponse('cmdline');

Ça ne sert à rien de modifier ça, ça revient au même ;-)

@@ -63,7 +63,7 @@
     }
 
     protected function _finishResponse($rep){
-
+        $rep->flushContent();
         return $rep;
     }

Inutile. La réponse va être renvoyée au coordinateur, qui va alors appeler output(), qui elle même va faire le flushContent()...

             jContext::push($module);
-            $group->run($reporter);
+            $result = $group->run($reporter);
+            if (!$result) $rep->setExitStatus(jCoordinator::EXIT_STATUS_KO);
             jContext::pop();

Tu as oublié de changer en jResponseCmdline::EXIT_CODE_KO. même erreur un peu plus loin

lib/jelix/core/jCmdlineCoordinator.class.php : ok

lib/jelix/core/request/jCmdLineRequest.class.php : Il faut corriger certaines choses dont je viens de me rendre compte. Il faut rajouter

    public function allowedResponses(){ return array('jResponseCmdLine');}

Après tout, je pense que les autres types de réponses ne seront jamais utilisés.

lib/jelix/core/response/jResponseCmdline.class.php :

+    const EXIT_CODE_KO = 1;

Je pense que c'est facilement confondable avec EXIT_CODE_OK. Il est préférable de le nommer EXIT_CODE_ERROR.

+    public function setContent($content, $bufferize=false){

Est ce que addContent ne serait pas plus approprié ? (un rechercher/remplacer dans ton diff facilitera le renommage ;-) )

Il faudrait aussi surcharger la méthode sendHttpHeaders, qui ne devrait pas executer header:

protected function sendHttpHeaders(){
   $this->_httpHeadersSent=true;
}

lib/jelix/init.php : annuler les modifications comme dit plus haut

Autre chose : met à jour les cartouches de chaque ticket modifié, en indiquant ton nom, ainsi que le fichier CREDITS de lib/jelix/

de chaque ticket modifié

pardon, je veux dire, de chaque fichier modifié

Voila la nouvelle version qui tient compte de tes remarques. J'ai teste tout ca avec attention. Peut etre que cette fois c'est la bonne :-)

• il y a des EXIT_STATUS_KO qui traînent encore.

Dans flushContent(), il manque le vidage de la variable _buffer. Si je ne me trompe pas, avec ta version actuelle, si on fait un flushContent et que l'on continue d'appeler addContent, lors du prochain flush ça réaffichera le buffer qui a déjà été flushé.

Corrige ces deux petites erreurs et ça ira, tu peux commiter.

Par vidage, je veux dire bien sûr $this->_buffer = ;