J'ai lu, et très franchement, je ne suis pas plus avancé....
Si je devais faire un choix "est-ce que je vais utilisé Hoa pour ma prochaine application", ma réponse serait "Non, car je ne sais pas à quoi peut bien me servir cet outils".

D'après ce que j'ai compris de la doc, je peux :
- importer et créer des bibliothèque Hoa
- gérer et créer des exceptions
- utiliser des abonnements/notification (ce qui a l'air intéressant)
- utiliser une sorte de protocole qui abstrait tout les accès à toutes les données.

J'ai donc compris comment on pouvait écrire :

$a = 42;
echo $a;

Ca donne :

from('Hoa')-> import('Registry.~');

Hoa\Registry::set('a, 42);
echo resolve('hoa://Library/Registry#foo');

Je vais me permettre la liberté d'un commentaire...

Hoa ? Oui, tenter de me convaincre consisterait à prêcher un converti. Pourtant, je n'ai à ce jour rien construit du tout avec Hoa. Pourquoi ? Essentiellement à cause d'une cruelle absence de documentation sur certains éléments essentiels et pratiques. Comment fonctionne, et donc comment puis-je utiliser, un pattern MVC avec Hoa, où dois-je configurer quoi, quel fichier dois-je créer (ou faire créer... et donc comment) et à quel endroit, comment définir ma propre architecture dans la configuration de Hoa, etc.. ?

Il y a dans le projet Hoa des solution qui sont à mon sens largement en avance par rapport à ce qui existe dans le Zend Framework ou dans Symfony parce que souvent tout simplement absentes de ces derniers. L'implémentation de praspel est à mon avis un outil particulièrement brillant quoi que puissent en dire certains détracteurs : pourtant, ce serait une manière d'aborder le TDD avec simplement des connaissances de base en expressions régulières et de la logique mais sans devoir se goinfrer toute la documentation d'un PHPUnit. Le système Hoathis permettant d'intégrer ses propres libraires sans tout casser est aussi à mon sens un «+» notable tout aussi brillant, et dès que j'aurai la possibilité de l'utiliser, ma première priorité sera de ré-écrire plus proprement mes packages d'accès aux données et mon package de gestion de formulaires. Mon idée générale, c'est surtout de ne pas devoir réinventer d'autres aspects d'un framework pour lesquels j'ai plus de difficultés d'approche comme par exemple les ACL ou encore la gestion des erreurs/exceptions ou que sais-je encore. J'utilise bien sur des systèmes maison pour ça mais je suis tout à fait conscient que les solutions des frameworks du type Hoa sont largement plus avancées et efficaces que mes bricolages.

En résumé, je dirais que la sortie d'une version beta, alpha, gamma voire pourquoi pas zeta si le cœur vous en dit, en fait, je m'en tape, ce qui m'intéresserait en revanche au tout premier plan, c'est la sortie d'une documentation claire, complète et claire et illustrée d'exemples. Il ne faut pas négliger un point : l'utilisateur « sérieux » est en entreprise et il n'a pas forcément le temps de se farcir des centaines ou des milliers de lignes de codes pour comprendre comment fonctionne telle ou telle fonctionnalité, comment tel élément dépend ou non de tel autre et comment utiliser intelligemment le tout : il n'est pas question de remettre en cause l'architecture du framework, il est question de l'utiliser à son plein rendement en perdant le moins de temps possible.

Pour faire un comparatif simpliste : supposons que j'écrive une classe de gestion d'accès aux données, l'utilisateur n'a nul besoin de savoir quelle sorte de recette j'ai suivi pour faire ma tambouille, il veut savoir quelle méthodes sont disponibles, quels paramètres sont attendus et quels retours sont possibles. Donc j'écris une classe, je documente les méthodes publiques, et je publie ça, l'utilisateur peut rapidement découvrir si ça répond à son besoin ou pas et il fait ou non le choix de continuer dans cette voie. C'est pareil au niveau d'un framework. Si je veux construire tel type d'application, est-ce que le choix de Hoa est plus pertinent que ZF ou Symphony ? N'oublions pas non plus un point essentiel : des développeurs capables de comprendre un fonctionnement rien qu'en lisant un code a un niveau tel que le framework Hoa, ça ne court pas spécialement les rues, et je suis certain que même dans les amphis d'universités spécialisées, il y a quelques étudiants qui pourtant baignent dedans toute la journée qui y perdent leur latin en 10 minutes : que pourrait-il en être d'un développeur autodidacte qui bosse dans une petite agence Web ou une petite SSII...

Enfin bon, voilà mon avis : si vous êtes étudiants, je vous encourage vivement à suivre le développement du projet Hoa, je suis convaincu depuis des années qu'il y a là un avenir professionnel solide. Si vous êtes en entreprise, je n'ai pas de conseils à vous refiler, je ne suis pas qualifié pour ça, mais si votre boss est assez généreux pour vous payer quelques heures à ne rien faire (on peut rêver) exploitez ces heures dans des essais avec Hoa-project

Comment ça je suis de parti-pris ?

Hey ,

Dire que c'est imbuvable n'est pas une critique constructive. Précise ce qui te dérange, les choses à améliorer etc. Merci .

Hey (bis) ,

L'exemple d'utilisation du registre statique est utilisé pour montrer que le protocole hoa:// ne sert pas qu'à abstraire les chemins mais peut aussi porter des données. Ça peut-être très pratique d'écrire ce genre de raccourcis.

La documentation est en cours d'écriture et il est plus qu'évident que ce qui est déjà posté est une introduction. Ça n'était pas clair pour vous ?

Hey (last) ,

Pour répondre aux critiques de Cyrano, le projet n'avance plus trop niveau code et toute la communauté se concentre sur la documentation justement. Je crois que tu es au courant de ça . Si d'ailleurs tu veux y participer, ce n'est pas un problème.

J'ai volontairement rendu la documentation inaccessible pendant un temps car le projet se cherchait une philosophie et que ça demandait une quantité de temps monstrueux pour mettre à jour la documentation. Maintenant que le projet est sur des rails solides, la documentation arrive rapidement avec en tête un manuel d'apprentissage (qui est plus adapté à l'apprentissage de Hoa que pourrait l'être un manuel de référence).

Enfin, je tiendrai une conférence sur Hoa au PHP Tour 2011 de Lille le 24 et 25 novembre. La documentation sera bien plus épaisse et le discours plus travaillé (je n'ai pas réagi sur la comparaison Hoa vs ZF vs Sf mais franchement, rien à voir ).

Enfin, je tiendrai une conférence sur Hoa au PHP Tour 2011 de Lille le 24 et 25 novembre. La documentation sera bien plus épaisse et le discours plus travaillé

Ça, ce serait pour moi une excellente raison d'aller à Lille assister au forum juste pour ça

(je n'ai pas réagi sur la comparaison Hoa vs ZF vs Sf mais franchement, rien à voir ).

Forcément, d'abord parce que tu es plongé dedans jusqu'aux oreilles et que cette immersion complète te donne une vision très largement plus complète. Mais mets-toi un instant dans la peau du développeur qui ne connait pas un framework plus qu'un autre entre Hoa, ZF, Sf, Cake et autres, comment devrait-il effectuer son choix et surtout comment pourrait-il voir et comprendre rapidement la différence d'approche de conception générale ? Pour ma part, je dirais que j'ai une idée des grandes lignes parce que ça fait longtemps que je garde un œil sur le développement de Hoa, mais ça reste quand même assez flou sur bien des points, ce le sera d'autant plus pour celui qui entend parler pour la première fois de Hoa

La conférence aura le mérite de formuler un discours plus clair à propos de la différence entre frameworks et bibliothèques justement.

La conférence aura le mérite de formuler un discours plus clair à propos de la différence entre frameworks et bibliothèques justement.

http://fr.wikipedia.org/wiki/Hoa_Framework

C'est effectivement pas très clair la différence...

Un « contributeur » a créé l'article sur Wikipédia avec le mauvais nom et impossible de le supprimer depuis … Autre lien : http://fr.wikipedia.org/wiki/Hoa

Un « contributeur » a créé l'article sur Wikipédia avec le mauvais nom et impossible de le supprimer depuis … Autre lien : http://fr.wikipedia.org/wiki/Hoa

je faisais que suivre le lien suivant

http://fr.wikipedia.org/wiki/Liste_de_frameworks_PHP

bon plus sérieusement, la différences entre framework et bibliothèques je vois pas, c'est quoi en fait?

Il y a effectivement un problème de définitions pas toujours très clair dans l'esprit de pas mal de monde.

Les bibliothèques sont constituées de classes ou de packages de classes indépendants les uns des autres. ON peut en utiliser qu'une partie sans devoir obligatoirement disposer des autres. Les classes ou les packages sont construits pour traiter un problème spécifique, pour manipuler des données de façon particulière en les prenant sous une certaine forme en entrée et en les ressortant d'une autre manière. Chaque package doit, autant que faire se peut, être totalement indépendant des autres. Je dois par exemple pouvoir me servir d'un package d'accès aux données sans dépendre d'un autre package qui traite tout à fait autre chose. Et les bibliothèques ne doivent pas être dépendante d'un framework particulier : ainsi, je dois pouvoir choisir d'utiliser certaines classes du ZF et d'autres de Hoa sans que ça ne crée de conflit.

Le framework est un cadre de travail pour une application : Ce cadre est constitué d'un certain nombre de codes qui vont s'appuyer selon le besoin sur telle ou telle classe ou package extrait d'une bibliothèque (ou de plusieurs) et au besoin établir le lien entre différents package pour effectuer des traitements complexes. Le framework par exemple va définir l'architecture, les chemins d'accès aux éléments requis pour tel ou tel traitement, ou encore va définir la gestion d'erreurs. Prenons un exemple : dans une application montée en MVC, la répartition des fichiers selon la partie à laquelle ils appartiennent (M, V ou C) relève du framework, pas des bibliothèques.

Pour faire dans le très succinct : le framework, c'est l'architecture de l'application, les bibliothèques, ce sont les traitements de données.

[...]
Pour faire dans le très succinct : le framework, c'est l'architecture de l'application, les bibliothèques, ce sont les traitements de données.

Dans ce cas là, ZF et Symfony (2, surtout) sont des bibliothèques ...
L'un comme l'autre viennent avec une chiée de librairies, et l'une d'entre elle est le module MVC permettant de tout mettre en marche avec un minimum de configuration.

Pour moi, un Framewok (cadre de travail), est un ensemble de pratique de codage dont la finalité est de coder plus rapidement en se concentrant sur le fonctionnel en ne réinventant pas la roue à chaque fois.
La tendance actuelle est que chaque framework embarque son module MVC, et cela apporte donc une souplesse énorme au niveau de l'organisation des projets (maintenabilité, évolutivité, documentabilité, ...), mais il serait faux de dire que ZF et Symfony sont complètement autiste sur leurs librairies.
Exemple : il est très simple d'utiliser des librairies Zend dans Symfony (je le fait depuis des années pour Zend_Lucene), et chaque module important de Symfony est une librairie qui peut se télécharger seule (cf. http://components.symfony-project.org/)

Bref, tout ce blabla pour dire que la frontière entre Framework et librairie est floue, voire inexistante.
Toutefois, et la conclusion de Cyrano me pousse dans cette idée, j'ai l'impression que, dans la tête des gens, un Framework est une librairie qui dispose d'un module MVC.

Bref, tout ce blabla pour dire que la frontière entre Framework et librairie est floue, voire inexistante.
Toutefois, et la conclusion de Cyrano me pousse dans cette idée, j'ai l'impression que, dans la tête des gens, un Framework est une librairie qui dispose d'un module MVC.

Précisément, d'où la nécessité d'établir la distinction

Bref, tout ce blabla pour dire que la frontière entre Framework et librairie est floue, voire inexistante.
Toutefois, et la conclusion de Cyrano me pousse dans cette idée, j'ai l'impression que, dans la tête des gens, un Framework est une librairie qui dispose d'un module MVC.

Précisément, d'où la nécessité d'établir la distinction

Mouais, pas convaincu :/

J'ai le sentiment que c'est le fait justement le fait que créer cette distinction qui entraîne le soucis de compréhension de Hoa : si ce n'est pas un framework, c'est pas bien.
Et bien non, justement, c'est pas ZF ou Symfony, mais c'est pas mal du tout

La première distinction que l'on peut faire entre bibliothèques et frameworks pour l'utilisateur c'est l'automatisation des tâches. Le framework arrive avec une multitude d'outils (pilotables en ligne de commande par exemple), qui font des traitements sombres et obscures, dans lesquels il ne faut surtout pas interférer. Les bibliothèques, quant à elles, te proposent de tout faire à la main.

Dit comme ça, ça sonne moins bien. Mais l'avantage des bibliothèques est que l'utilisateur comprend tout à fait ce qu'il fait, ce qu'il se passe et est ainsi capable d'adapter les bibliothèques à son besoin précis. Et pour réussir à rivaliser avec des outils « automatiques », elles doivent être très abstraites et extrêmement modulaires pour être utilisées facilement et rapidement (super API, super abstraction etc.).

C'est une des nombreuses distinctions possibles, mais je pense que c'est la plus compréhensible.

À ça, j'ajoute que Hoa propose un environement pour développer et partager ses propres bibliothèques. Et si on se base sur cet environnement, on gagne en maintenance (vis à vis de Hoa, des applications basées sur Hoa et même de PHP).

Nouveaux chapitres cette semaine pour la documentation.