Je crois qu'il serait intéressant de voir ce qui se dit sur le sujet dans sa globalité sur un fort intéressant billet faisant écho à un « manifeste micro PHP ».

Pour ce qui me concerne, j'approuve sans problème.

L'ouverture de ce sujet et ce qui y est développé est à mon avis du plus grand intérêt et va dans le sens d'une notable amélioration vers une meilleure diffusion de Hoa. L'idée de reprendre certains tutoriels à la manière de Jobeet me semble la plus appropriée. On construit une véritable application qui n'est pas limitée à un « hello world » et on découvre en le faisant les avantages de l'utilisation de Hoa. C'est un peu comme la cuisine, pouvoir tester rapidement et goûter, c'est plus motivant que de devoir se farcir un bouquin de cuisine avant de faire quoi que ce soit. On commencera avec quelque chose de relativement simple et on pourra ajouter des éléments de plus en plus complexes au fur et à mesure qu'on se sentira à l'aise. Les premières fois, on fera de simples œufs au plat, mais avec la pratique, on découvrira qu'il est beaucoup moins compliqué qu'il n'y paraissait de faire des œufs en meurette.

Le but final reste quand même de construire des applications, Hoa n'est pas une fin en soi. Or ces applications ne peuvent être construites en dépit du bon sens. Des outils comme Hoa (ou d'autres, Symfony, ZF, Cake, etc..) sont utilisés en premier lieu pour une raison fondamentale : on construit une architecture pour rendre l'application pérenne et beaucoup plus facilement et rapidement maintenable. Par ailleurs, on permet aussi au développeur de se concentrer davantage sur son code métier, les problèmes génériques étant déjà traités par les librairies mises en œuvre par le framework choisi.

Sur les échanges que j'ai eu avec Hywan sur la documentation, je vais résumer sommairement quelques points.
-1- La distinction entre « contributeur » et « utilisateur » me semble importante. Hoa apporte des solutions parfois très novatrices, parfois plus classiques, mais le tout avec une philosophie générale dans la manière de traiter tel ou tel aspect d'un développement. Mais si on veut envisager de voir grossir les rangs des contributeurs, il va falloir commencer par convaincre les utilisateurs de la pertinence du choix de Hoa pour leur travail au quotidien.
-2- Les utilisateurs potentiel sont éventuellement employés dans des entreprises avec certaines obligations et ne peuvent pas nécessairement se consacrer à plein temps sur la lecture complète d'une documentation avant de pouvoir décider si le choix est approprié ou non de se servir de telle ou telle solution : Hoa en est une parmi d'autres, mais leur client attend son application et il ne dispose pas d'un temps infini pour arrêter une décision.

Donc, ma vision à cet égard est assez simpliste, et c'est sous l'angle de vue du développeur d'entreprise (l'utilisateur) qu'il convient de se placer pour la lire : je ne connais pas le fonctionnement de Hoa, comment il traite quoi que ce soit. Mais je suis bien entendu convaincu du fait que Hoa ne traite pas en vrac n'importe quoi n'importe comment. Il y a un fonctionnement par défaut pour pas mal de choses et la possibilité ou non de procéder autrement ou d'adapter par rapport à un existant... ou pas. Actuellement, je construis une sorte de mini ERP et la toute première chose que j'ai mise en place, c'est l'architecture générale : comment répartir les librairies, mes contrôleurs, mes fichiers media (CSS, js, Images), le moteur général, mon code métier... précisément pour évacuer tout risque de duplication inutile et faciliter également la maintenant à court moyen et long terme. Ce faisant, je ne m'inquiète que très moyennent à ce stade des librairies elles-même : ultérieurement, s'il s'avère que tel ou tel package ne correspond pas à mon besoin, il sera toujours temps de trouver une solution alternative. À ce stade, c'est hors de propos : distinction entre framework et librairie, je m'occupe de la partie framework : comment sont gérés ces problèmes d'architecture est LE point que je dois résoudre en tout premier lieu.
Le tuto de base doit présenter la solution telle que traitée par défaut par Hoa, et éventuellement expliquer succinctement pourquoi tel ou tel choix plutôt qu'un autre a été fait. Dans un tuto plus complet, on doit pouvoir trouver relativement facilement comment faire pour utiliser une architecture qui serait différente pour quelque raison que ce soit, si bien entendu la chose est possible.

On utilise pas une masse de 4kg pour enfoncer des clous de vitrier. Lorsqu'on en arrive à développer en s'appuyant sur un framework, ce n'est en général pas pour se faire une page personnelle sauf à titre didactique comme pour le Gordon's blog par exemple. On a donc en principe pas affaire à des néophytes en matière de programmation en PHP. Ces développeurs ont déjà rencontré pas mal de cas, sont passés par des phases diverses et variées et ont appris petit à petit à coder de façon plus rationnelle. L'utilisation d'un framework va encore améliorer la qualité de leur travail... pour autant qu'ils puissent rentrer dedans sans se prendre la tête plus que de raison. La formule est peut-être un peu lapidaire, mais j'aurais tendance à dire que si c'est compliqué, alors ce n'est probablement pas la meilleure solution. On a à construire des applications professionnelles de façon efficace et c'est tout l'intérêt de solutions comme Hoa ou d'autres qui permettent de s'affranchir du développement de pas mal de choses très génériques. À l'usage, on découvre petit à petit au fil de l'écriture de son code métier quels packages de Hoa permettent de traiter tel problème, mais à ce stade, on sait déjà comment on doit répartir les fichiers sans devoir s'interroger à chaque fois. C'est une question assez classique que j'ai pu relever par exemple à propos du ZF : un développeur bloque sur un message d'erreur à cause d'un contrôleur non trouvé alors que son fichier existe bien mais n'est pas au bon endroit : si on ne comprend pas au départ comment fonctionne la gestion de l'architecture par le framework, on perd un temps fantastique et c'est pour ça qu'à mon humble avis, c'est la première partie qu'une documentation doit traiter. Ensuite, pour l'utilisation des librairies, je n'ai nul besoin de savoir exactement comment tel ou tel package fonctionne en interne : je n'ai besoin que de connaître le nom des classes et méthodes publiques ou statiques accessibles, ce qu'elle font et avec quels paramètres, obligatoires ou optionnels, à la manière de la documentation de PHP.

Plus tard, (comme l'a d'ailleurs fort justement fait observer Raphaël) c'est à dire lorsqu'un utilisateur devient suffisamment familier avec la solution, il peut être intéressé pour aller plus loin en apportant des nouveautés ou des alternatives plus intéressantes à tel ou tel élément. Mais à mon avis, ça veut aussi dire qu'on a affaire à des gens techniquement plus avancés capables de rentrer dans le cœur du framework : le plus souvent, le contributeur fera ça en marge de son travail régulier parce qu'en entreprise, il n'a pas le temps pour ça sauf en de rares cas où il devra développer un élément pour résoudre un problème qui n'est pas traité dans le framework parce que très spécifique ou trop marginal.

my 2¢

Mouais, ça me parle beaucoup moins, peut-être l'exemple utilisé n'est-il pas approprié, je sais pas. Mais là tu fais un fichier xml avec yield/form/input/etc... comment j'introduis une variable PHP là dedans ? Je mets le XML dans une variable le tout dans un fichier PHP et je récupère avec un sprintf() ou quelque chose du genre ? Ou encore je peux utiliser du HEREDOC ? Et comment je combine ça avec les boucles mentionnées plus tôt ?

J'ai le sentiment que pour la doc, il faudra un exemple de base, pour ça ta vidéo me semble excellente, mais aussi un exemple beaucoup plus complexe avec les détails, modèles de code, options et alternatives.

Pas vraiment, c'est, somme toute, un moindre mal.

Allez, une autre puisqu'on est sur cette lancée : supposons que je travaille avec une équipe de développement. Mes pages sont montées à la base par un web-designer qui me fournit des maquettes en HTML. En résumé, le code est déjà prêt, je n'ai qu'à l'intégrer dans l'application en remplaçant un paquet de valeurs mises là pour meubler et valider l'aspect visuel par des variables.

Sauf erreur d'interprétation de ma part,  il va falloir que je ré-écrive en partie le code en HTML5, lui ajouter les attributs « exotiques pour la validation Praspel» et hoa::xyl va me recracher le formulaire avec le même code que le code d'origine de la maquette. Le problème est secondaire si mon web-designer est un collègue employé de la même boite que moi et il suffit de le former en interne à cette nouvelle manière de faire pour qu'il me ponde des maquette quasiment directement en HTML5 avec les bons attributs...(quoique je n'aime pas le mélange des genres, j'y reviens plus loin), mais si j'ai affaire à un sous-traitant ponctuel qui ne sera pas forcément ouvert à l'idée de devoir se mettre à xyl qu'il n'utilisera peut-être qu'une fois par an pendant deux jours.

Quand je dis que je n'aime pas le mélange des genres, voici pourquoi : en développement professionnel, on tend vers des modèles MVC : séparation des couches données/traitement/affichage. J'ai tendance à dire qu'au niveau du travail lui-même, on doit faire la même chose si possible : à chacun son métier : les web-designer n'ont nul besoin de comprendre ni même de connaitre la programmation, il doivent juste maitriser à fond le langage dans lequel seront écrites les pages envoyées vers les navigateurs, le programmeur n'a, à la limite, pas vraiment besoin de maitriser les normes HTML aussi loin que ça par contre il doit maitriser la programmation : en somme, là aussi on sépare les couches et on limite les dépendances entre les membres.

Donc la question assez globale : l'apprentissage de xyl, ce sont combien de mots-clés et combien de règles ? S'il y en a beaucoup, il sera difficile de l'imposer à qui que ce soit, mais sinon, on peut peut-être l'envisager facilement ?

Dernier point HS : un bug quand j'ai cliqué sur le lien « Reply », ça a donné :