J'ai pas lu en profondeur le code, mais rien que ce qui est montré par katagoto me donne pas très confiance (contrairement à ZF ou Sf où le code me donne un grande confiance et où donc mon opposition n'est qu'idéologique).

Bon, déjà, il y a plein de code commenté : ca fait sale. On va me rétorquer que c'est un détail, mais je trouve que le code commenté montre que le développeur a pas forcément confiance en ce qu'il fait et s'il va devoir vraiment supprimé ou _garder pour plus tard_ ses morceaux de code (cela n'arrive jamais).

Du coup, comme les fonctions se retrouvent vide, les commentaires de celle-ci mentent ( quand est-ce que les dev comprendrons que les commentaires c'est mal), et du coup, on s'interroge pour savoir pourquoi cette satanée classe n'est pas abstraite avec toutes ces fonctions vide ...

Ensuite, on met pas mal de temps à comprendre vraiment ce que fait cette classe, je me suis demandé si elle était encore utilisée ... D'après ce que j'ai compris, elle permet de créer un objet de connexion vers une BD en fonction d'un tableau de paramètre. Ce dernier point n'étant pas certain, vu que le constructeur défini le $this->parameters à un Hoa\Core\Parameter pour mieux le redéfinir après via un Array passé en paramètre du constructeur.

Je pense également, qu'il y a un gros problème sur le singleton qui, étant donné qu'il est paramétrisable, ne peut pas être un singleton :
getInstance($p1) et getInstance($p2) vont renvoyer les même objets... Ce qui est d'autant plus curieux que dans la classe Dal juste à coté, on a bien pensé au multiton.

Donc, bref, c'est un peu cracra et en regardant rapidement le reste du code on voit pas mal de truc assez tordu de ce style ...
Dans le code de Sf ou de ZF, où j'ai fait à peu près la même chose (lire quelques fichiers de code source), on se rend compte que :
- c'est très propre
- il y a très peu de construction tordu
- les seuls points où j'ai trouvé à redire sont discutable et dépendent plus du style de programmation adopté.
- c'est moins compliqué à comprendre (i.e. la lecture est plus aisé)

Bon, déjà, il y a plein de code commenté : ca fait sale. On va me rétorquer que c'est un détail, mais je trouve que le code commenté montre que le développeur a pas forcément confiance en ce qu'il fait et s'il va devoir vraiment supprimé ou _garder pour plus tard_ ses morceaux de code (cela n'arrive jamais).

Du coup, comme les fonctions se retrouvent vide, les commentaires de celle-ci mentent ( quand est-ce que les dev comprendrons que les commentaires c'est mal), et du coup, on s'interroge pour savoir pourquoi cette satanée classe n'est pas abstraite avec toutes ces fonctions vide ...

J'hallucine complètement en lisant de pareilles énormités... Les commentaires ne sont pas là pour faire joli. Je peux concevoir qu'il doit y avoir une marge entre pas de commentaires du tout et trop de commentaires inutiles, mais ne pas commenter du tout un code est une aberration, et ça peut, dans la mesure où les commentaires sont réellement pertinents, servir à générer automatiquement une documentation d'API avec un outil du type PHPDocumentor, indépendamment d'une documentation fonctionnelle. Ça sert aussi à s'y retrouver lorsqu'on revient sur un code après plusieurs semaines/mois/années pour comprendre plus rapidement comment fonctionne quoi et aller à l'endroit qu'on a besoin de voir/modifier/corriger.

Ensuite, il me semble que critiquer négativement les méthodologies mises en œuvre dans le code de Hoa, c'est assez arrogant. J'ajoute que comparer avec le ZF ou SF, c'est sans grand intérêt. Hoa comme les autres restent des outils de travail. Chacun est plus ou moins approprié pour un besoin déterminé, point barre. Si Hoa ne convient pas à votre besoin du moment, ça n'en fait pas un mauvais framework, ça en fait un outil inapproprié pour vous en ce moment, ça ne va pas plus loin, et c'est valable pour n'importe quel framework. C'est comme comparer des voitures de marques différentes. On aime tel modèle et pas tel autre, il y a certes certains critères subjectifs comme le design, mais d'autres critères plus objectifs comme les performances, l'ergonomie, la fiabilité, et ce qu'on veut faire avec à savoir se déplacer localement, se déplacer sur de longues distances, faire de la course de vitesse, etc...
Pour l'instant avec les frameworks, je vois surtout ici des critiques sur des points plutôt subjectifs, et d'autres sur des points qui seraient plus objectifs s'il n'y manquait la démonstration technique des choix dénoncés comme étant mauvais : c'est parler dans le vide, gratuit, sans intérêt et c'est une perte de temps.

Et n'allez pas croire que je sois un utilisateur de Hoa qui défend son outil, je n'utilise ni Hoa, ni le ZF ni SF, je me sers actuellement d'un montage personnel même s'il peut m'arriver d'utiliser telle ou telle bibliothèque issue d'un des frameworks cités plus haut. J'attends la doc de Hoa comme beaucoup pour aller plus loin, mais en apportant occasionnellement des suggestions ou des alternatives à tel ou tel élément : qu'ils soient pris en compte ou non feront que j'adopterai ultérieurement ou non l'outil pour un projet donné.

Pardon, je me suis mal exprimé : le code commenté c'est ca :

public function getBase ( $name ) {

        /*
        $oldBase = $this->getKeyword('base');

        $this->setKeyword($name);

        $directory = $this->getFormattedParameter('base.directory');
        $file      = $this->getFormattedParameter('base.file');

        require_once $directory . $file;

        $class     = $this->getFormattedParameter('base.class');

        if(!class_exists($class))
            throw new \Hoa\Database\Exception(
                'Cannot find the base class %s in %s.',
                1, array($class, $directory . $file));

        $this->setKeyword($oldBase);

        return new $class();
        */
    }

Il s'agit d'une critique au niveau code uniquement, je ne me suis pas permis de critiquer l'ensemble car je n'ai pas encore essayé. Je procède donc à un sondage du code, tel que je le fais pour tous logiciel que j'utilise.

Sur une version beta ? Tu as du temps à perdre alors

Lire du code est une activité passionnante !

Je suis très surpris que les développeurs ne le fasse pas plus. C'est d'ailleurs, en général, plus complexe qu'écrire du code.

Je ne vois pas trop ce que la version béta viens faire là dedans, on demande un avis sur Hoa avec un lien pour le télécharger : j'y vais, je télécharge, je donne un avis : les dév veulent sans doute un avis sur cette version en cours, donc la béta ....

J'entends bien, mais dénoncer la présence de code mis en commentaire dans une version beta est un non-sens : la version beta n'est forcément pas totalement stable et il y aura du coup des éléments de code en cours de stabilisation qu'on peut avoir besoin de désactiver pour ne pas bloquer autre chose sur quoi on travaille. C'est pour ça que je dis que s'arrêter sur ce type d'élément est une perte de temps. Je trouverais ça effectivement beaucoup moins élégant dans une version livrée comme finale et stabilisée.

J'ai essayé toute les archives par de répertoire bin (désolé pour le e en trop :/

Ce dossier est disponible pour la beta5 qui sort cette semaine. Oui, il faut taper sur le trunk. J'avoue que la documentation serait presque en avance sur les releases pour une fois, mais ce sera réglé avec la RC.

mercurial utile peux être pas, perso j'en ai pas besoin (ni même git ou pas) même pas sujet c'est hors sujet

C'est totalement hors-sujet . Mercurial est très pratique pour Hoa, plus que ne l'était SVN. De toute façon, comme les archives compressées ou Phar sont présentes, je ne vois pas où le problème. Tu as largement le choix . Sont en préparation un canal PEAR et même Aptitude.

- installer Hoa dans /usr/local/ pourquoi ? est ce que l'on est obligé d'avoir un dédié pour l'utiliser ?

Hoa peut s'installer où on veut. L'aspect framework utilise un fichier Core.link.php qui peut se redéfinir à travers le script whereishoa (et whereishoa.bat). De fait, ton application va toujours inclure Core.link.php, qui fera le lien vers Hoa, donc peu importe où ce dernier est situé. On conseille /usr/local/lib/hoa pour les Unix et C:\Program Files\Hoa pour Windows (voir la section à propos du confort). Ce n'est nullement une obligation, juste une proposition.

je sais bien, mais je pense que l'accent est trop donnée dessus, une indication d'une installation standard sans pré requis serait plus cool

Et on prend quoi comme chemin pour les exemples ? De toute façon, l'endroit où est installé Hoa n'a aucune importance surtout avec son aspect framework car tu vas inclure un fichier qui s'appelle Data/Core.link.php qui est un lien vers le noyau de Hoa. Ce lien peut être modifié avec la commande Data/Bin/whereishoa (ou whereishoa.bat).
Après, on parle bien de confort. D'autres frameworks demandent aussi de s'installer dans /var/www ou bien /usr/local/lib comme je le fais. Ça n'a rien de particulier, juste une bonne pratique .

- une fois l'install fait j'ai voulu testé bhoa et heu j'arrive pas a avoir une page php deja existante (ha oui pas faite avec hoa).

Je serais interessé de connaître ta manipulation et du message d'erreur que tu as eu. Bhoa exécute du PHP à travers HTTP, avec ou sans Hoa, ça n'a rien à voir.

je lance la console, je vais dans répertoire qui me convient (avec des pages php puisse d'après ce que j'ai compris il s'agira du "docroot" du serveur ? et je lance : hoa bhoa
réponse

H:\web\docRoot\test>hoa bhoa
Server is up, on tcp://localhost:8888!
Root: H:\web\docRoot\test.

Waiting for connection

(au passage pb d'encodage sur la console win)

Ô£û GET /index.php
Ôå│ PHP FastCGI seems to be disconnected (tried to reach tcp://localhost:9000).
Ôå│ Try $ php-cgi -b localhost:9000
or $ php-fpm -d listen=localhost:9000

a l'essai d'affichage d'une page.

Le DOS ne supporte pas Unicode. Un patch est en cours mais l'encodage utilisé par le DOS est très faible en possibilité …

ha oui j'ai oublié le php-cgi& autre console re test

Ô£û GET /index.php
Ôå│ PHP FastCGI seems to be disconnected (tried to reach tcp://localhost:9000).
Ôå│ Try $ php-cgi -b localhost:9000
or $ php-fpm -d listen=localhost:9000

on envoi le php-cgi -b localhost:9000

d'après la doc

Attention à bien démarrer PHP FastCGI afin que Bhoa puisse exécuter PHP. Normalement, si Bhoa n'arrive pas à joindre PHP FastCGI, il le signalera de cette façon :

✖ GET /index.php
↳ PHP FastCGI seems to be disconnected (tried to reach tcp://localhost:8888).
↳ Try $ php-cgi -b localhost:8888
or $ php-fpm -d listen=localhost:8888

et pourtant je l'ai bien lancer (au passage php-fpm n'existe pas chez moi) je tourne sous w7 X64 test avec php5.4 (oui je sais c'ets une alpha) test avec php5.3.6 idem :/

PHP-FPM n'existe pas sous Windows, c'est indiqué dans le manuel de PHP. Ils y travaillent mais ce n'est pas simple. Mais si tu utilises PHP-CGI, ça ne devrait pas poser de problème. Je te propose de venir sur le forum de Hoa (forum.hoa-project.net) ou sur le chat IRC (irc.freenode.net #hoa_php) pour qu'on en parle. On ne va pas faire du debug ici. J'ai besoin d'avoir plus d'informations sur ta configuration Windows.

Merci pour le retour .

Pour répondre à katagoto et epommate2, le paquetage Hoa\Database est en total refonte (lire le forum de Hoa). On est sur une beta et le trunk n'est pas à suivre au jour le jour. Aller lire le code du noyau ou des flux, ceux-ci sont fixés et ne changeront pas.

Ok, bon, ben j'ai commencé par Core.php en pensant que c'est ici le début.

Dans le constructeur, quand je vois ca :

  if(false !== $wl = ini_get('suhosin.executor.include.whitelist'))
            if(false === in_array('hoa', explode(',', $wl)))
                throw new Exception(
                    'The URL scheme hoa:// is not authorized by Suhosin. ' .
                    'You must add this to your php.ini or suhosin.ini: ' .
                    'suhosin.executor.include.whitelist="%s", thanks :-).',
                    0, implode(',', array_merge(
                        preg_split('#,#', $wl, -1, PREG_SPLIT_NO_EMPTY),
                        array('hoa')
                    )));

Je me dis que c'est quand même pas très beau, surtout qu'en le refactorisant, je pense avoir trouvé un bug : il manque un sprintf à l'interieur du new Exception. Et j'ai pas compris l'interet du preg_split ...

isHoaURLAuthorizedOrThrowAnException()	;

function isHoaURLAuthorizedOrThrowAnException(){

	//FIXME : et la blackList !!

	$whiteList = ini_get('suhosin.executor.include.whitelist');
	if (! $whiteList){
		return true;	
	}
	if (in_array('hoa',explode(",",$whiteList))){
		return true;	
	}
	
	$message = "The URL scheme hoa:// is not authorized by Suhosin. ' .
            'You must add this to your php.ini or suhosin.ini: ' .
            'suhosin.executor.include.whitelist="$whiteList,hoa" , thanks :-)";

	throw new Exception($message);
}

Le nom de la fonction fait également penser qu'elle fait trop de chose et qu'une classe spécifique a envie de sortir de là ...

(j'ai du coup apris ce qu'était Suhosin

Ok, il s'agit d'un détail, mais c'est ca qui compte quand on regarde l'élégance d'un code source ...

Tout d'abord, le code original est :

        if(false !== $wl = ini_get('suhosin.executor.include.whitelist'))
            if(false === in_array('hoa', explode(',', $wl)))
                throw new Exception(
                    'The URL scheme hoa:// is not authorized by Suhosin. ' .
                    'You must add this to your php.ini or suhosin.ini: ' .
                    'suhosin.executor.include.whitelist="%s", thanks :\-).',
                    0, implode(',', array_merge(
                        preg_split('#,#', $wl, -1, PREG_SPLIT_NO_EMPTY),
                        array('hoa')
                    )));

J'ai ajouté un \ pour que le forum n'ajoute pas de code HTML en rapport avec le smiley.
De plus, ça n'a rien de sale ou d'une mauvaise pratique, on vérifie que Suhosin n'empêche pas d'utiliser le protocole hoa://. Il ne manque pas de printf(), cela étend délégué au système d'exceptions qui supporte ça nativement justement (voir la section Exception, que tu devrais lire).
Le preg_split est utile pour correctement formatter et afficher le message d'erreur si jamais le paramètre de Suhosin est mal écrit (s'il contient un espace par exemple). Faire une méthode supplémentaire n'ajouterait rien à part ralentir le système car ce traitement n'est utile que dans le constructeur et n'a donc aucune raison d'exister dans une méthode à part entière.

Que tu trouves ce bout de code beau ou pas est très subjectif. Il est efficace, ne fait pas de traitements inutiles, supporte des erreurs communes etc.

Ah oui, les namespaces, quel bonheur Désolé, je me suis effectivement trompé sur ce point.

Une grosse qualité d'un framework c'est de pouvoir être lu facilement. Vu la difficulté que j'ai eu à lire la fonction __construct de la classe principale (et que je n'ai donc visiblement pas comprise complétement), je serais vraiment très hésitant à le choisir, car je n'ai pas vu de construction comme cela dans Sf ou ZF, c'est tout...

J'ai essayé toute les archives par de répertoire bin (désolé pour le e en trop :/

Ce dossier est disponible pour la beta5 qui sort cette semaine. Oui, il faut taper sur le trunk. J'avoue que la documentation serait presque en avance sur les releases pour une fois, mais ce sera réglé avec la RC.

[/quote]
je comprend mieux, peut être serait il bon de préciser que pour le moment la doc s'appuie sur le trunk et que donc il est préférable d'utiliser mercurial, après tout c'est une beta pourquoi.

mercurial utile peux être pas, perso j'en ai pas besoin (ni même git ou pas) même pas sujet c'est hors sujet

C'est totalement hors-sujet . Mercurial est très pratique pour Hoa, plus que ne l'était SVN. De toute façon, comme les archives compressées ou Phar sont présentes, je ne vois pas où le problème. Tu as largement le choix . Sont en préparation un canal PEAR et même Aptitude.

Oui oui le choix, mais étant donné que justement je l'ai je préfère dl une archive (et je les ai toute dl) et la pour le coup la doc diffère et c'est "perturbant"

- installer Hoa dans /usr/local/ pourquoi ? est ce que l'on est obligé d'avoir un dédié pour l'utiliser ?

Hoa peut s'installer où on veut. L'aspect framework utilise un fichier Core.link.php qui peut se redéfinir à travers le script whereishoa (et whereishoa.bat). De fait, ton application va toujours inclure Core.link.php, qui fera le lien vers Hoa, donc peu importe où ce dernier est situé. On conseille /usr/local/lib/hoa pour les Unix et C:\Program Files\Hoa pour Windows (voir la section à propos du confort). Ce n'est nullement une obligation, juste une proposition.

Je conçoit, mais comme déja indiqué ce n'est pas toujorus utilisable (cas des serveur mutalisé dans le web par exemple). L'utilisation du fichier Core.link.php pourquoi pas mais la doc n'en parle pas a ce moment la, il existe un outils pour cela c'est super, mais on va pas aller a la fin de la doc pour le savoir. La remarque est dans le sens "plus clair" on utilise Hoa où l'on souhaite et l'on utilise whereishoa pour configurer la chose. ceci devrait être indiqué au départ, dans l'installation

Je sais bien, mais je pense que l'accent est trop donnée dessus, une indication d'une installation standard sans pré requis serait plus cool

Et on prend quoi comme chemin pour les exemples ? De toute façon, l'endroit où est installé Hoa n'a aucune importance surtout avec son aspect framework car tu vas inclure un fichier qui s'appelle Data/Core.link.php qui est un lien vers le noyau de Hoa. Ce lien peut être modifié avec la commande Data/Bin/whereishoa (ou whereishoa.bat).
Après, on parle bien de confort. D'autres frameworks demandent aussi de s'installer dans /var/www ou bien /usr/local/lib comme je le fais. Ça n'a rien de particulier, juste une bonne pratique .

wé, donc pour exemple

Le DOS ne supporte pas Unicode. Un patch est en cours mais l'encodage utilisé par le DOS est très faible en possibilité …

je sais bien, c'était pour te l'indiquer, les message étant en anglais ca devrait pas trop poser de soucis, par contre les caractères "bizard entre wainting et la parenthèse derrière semble louche

pour hoa, le pb n'est pas résolus, par contre j'avais oublié une installation de zend server et du coup j'avais 3 php-cgi en fond et pour le je sais pas comment php fait le distinguo mais a priori pas comme il faut

je ne suis pas allé plus loin, des que j'aurais du temps j’essaierais des trucs simple sans fw, genre espace membre connexion sgbd etc

je te tiendrais au jus de mes soucis ou pas

si la doc était dispo en archive (genre mode hors ligne) histoire de pouvoir l'utiliser sans être connecter au net, ça serait pratique


@+

Tu as les archives *.next.format pour les versions du trunk ; par exemple : /Central/Hoa.next.phar.

Pour ton soucis de PHP-CGi, tu peux toujours faire ceci : Et le problème sera résolu.

La documentation est accessible hors-ligne mais il faut télécharger tout le site (accessible uniquement depuis Mercurial pour le coup) et lancer Bhoa avec Data/Bin/hoaw3 (myapp renommé quoi). C'est comme ça pour l'instant en attendant une version PDF .

Faire une méthode supplémentaire n'ajouterait rien à part ralentir le système car ce traitement n'est utile que dans le constructeur et n'a donc aucune raison d'exister dans une méthode à part entière.

Ah oui, tu considères qu'une fonction est juste là pour factoriser du code et pas pour organiser le code de manière plus lisible en découpant les responsabilités ou bien pour faire sauter des niveaux d'imbrications ?

Si, mais l'existence d'une méthode doit se justifier. Dans notre cas, elle ne sera jamais appelée depuis l'extérieur de la classe et elle sera appelée qu'une seule fois par la classe elle-même. L'existence de ce code comme méthode n'est donc pas justifiée, sauf si d'autres vérifications viendront s'ajouter (ce qui n'est pour l'instant pas le cas).