A nouveau, je pense que la notion de "Framework" tiens juste à la brique qui met en oeuvre automatiquement les autres briques.
Mais tout framework un tant soit peu évolué se repose avant tout sur des briques qui sont indépendantes.

Par contre, je pense qu'on touche un point important dans la popularité des framework, c'est cette possibilité, sans rien y comprendre, de le mettre en oeuvre rapidement.
Et même en tant que fervent défenseur de l'utilisation de Framework, je trouve ça stupide de ne pas comprendre comment il fonctionne, au moins sur les points importants. "Pour savoir si on utilise un outil, il faut savoir s'il répond au besoin" et si on ne comprend pas l'outil ...
Et du coup, on tombe sur l'explication de pourquoi certains utilisent (et défendent) tel ou tel outil à tord : parce qu'ils ne prennent pas de recul dessus.

je pense comme zeus, en fait c'était la question sous-jacente de mes dernières interventions sur ce topic, à savoir qu'il n'y a aucune différence entre les frameworks et les librairies, la seule raison de parler de ça c'est pour faire une différence entre zend, symfony et hoa, en gros c'est du marketing

C'est une forme de positionnement marketing d'une part mais ça montre une grosse différence philosophique d'autre part. Les approches ne sont pas du tout les mêmes. Avec un framework, les bibliothèques qu'ils construisent sont orientées vers des outils (on construit l'outil qui nécessite des bibliothèques). Alors qu'avec des bibliothèques, on ne connaît pas le contexte d'utilisation et encore moins les outils qui vont les utiliser. Ça demande une approche différente et une abstraction plus poussée.

De plus, dans Hoa tu trouveras des bibliothèques comme Hoa\Websocket, Hoa\Dns, Hoa\FastCgi, Hoa\Regex, Hoa\Zombie etc., qui ne sont pas forcément orientées Web mais développement assez « pointu » (spécialisé dans autre chose quoi).

C'est une forme de positionnement marketing d'une part mais ça montre une grosse différence philosophique d'autre part. Les approches ne sont pas du tout les mêmes. Avec un framework, les bibliothèques qu'ils construisent sont orientées vers des outils (on construit l'outil qui nécessite des bibliothèques). Alors qu'avec des bibliothèques, on ne connaît pas le contexte d'utilisation et encore moins les outils qui vont les utiliser. Ça demande une approche différente et une abstraction plus poussée.

Non on s'est pas bien compris, j'impliquais que ton discours n'était QUE un effort marketing pour donner une existence et un but différent à HoA, et je le crois toujours, il n'y a pas de différence entre framework et bibliothèque, il n'y a pas de philosophie différente et de "famille" de framework, il y a un message que tu essayes désespérément de faire passer pour différencier ton bébé des autres, je trouve ça intellectuellement malhonnête, je préférais largement que tu communiques sur ce qui fait vraiment l'interêt de ton HoA parce que ces considérations passent au dessus de la tête de la plupart des gens, et dépassent les bornes pour les autres...

Objection votre honneur

...il n'y a pas de philosophie différente et de "famille" de framework...

Je m'inscris complètement en faux contre cette assertion. C'est peut-être une question de définition ou de terminologie, mais la différence existe bel et bien. Si on remonte de quelques années aux débuts de la POO en PHP, chacun y allait de sa classe pour traiter un problème récurent de façon plus rationnelle et en factorisant un certain nombre de méthodes éparpillées voire redondantes : se sont alors constituées des bibliothèques de classes et de packages. Par la suite sont apparus des frameworks qui ajoutaient une couche plus spécifique pour organiser l'architecture des applications de façon plus efficaces et qui permettaient de cadrer plus intelligemment le développement d'une application en définissant une architecture ou encore des règles pour intégrer sa propre architecture.

Quand tu dis qu'il n'y a pas de familles de frameworks, je ne suis pas d'accord non plus : Les philosophies qui président aux développement du ZF et de Symfony pour ne citer que ces deux là sont totalement différentes. Zend a piloté avec une vision « générique » pour que ça puisse servir à peu près n'importe où, alors que du coté de Symfony (qui s'appelait du reste à l'origine Sensio Framework du nom de l'entreprise qui l'a développé), l'orientation était clairement vers les besoins exprimés par leurs clients et les besoins métiers des applications qu'ils construisaient pour leurs clients. Hoa de son coté a clairement fait la distinction entre les librairies et le framework dans deux parties différentes de l'architecture : les librairies peuvent être utilisées seules ou avec le framework si on veut faire un développement structuré en équipe où les règles sont bien établies et où on évite l'anarchie.

...je trouve ça intellectuellement malhonnête, je préférais largement que tu communiques sur ce qui fait vraiment l'interêt de ton HoA...

Là, je te trouve quand même vraiment gonflé, quoique dans la mesure où pour toi la différence entre framework et bibliothèque n'existe pas, je peux concevoir ton point de vue, mais je ne le partage évidemment pas.

HyWaN avec Hoa a une approche que je situerais personnellement entre ZF et Sf parce qu'il y a le coté générique du ZF avec des librairies qui ne sont pas obligatoirement destinées au web, et le coté entreprise de Sf. Ce qu'apporte en plus Hoa, c'est sur certains éléments des idées neuves, en matière de TDD par exemple avec Praspel, et la manière dont on peut « étendre » l'ensemble avec ses propres classes ou en utilisant des classes issues d'autres bibliothèques en utilisant Hoathis qui a été spécialement conçu dans ce but. Et puis la philosopie de Hoa est également indiquée dans la présentation : situé entre le monde de l'entreprise (et ses besoins en matière de développement) et la recherche, et à mon sens il faut entendre par là « recherche avancée » à un niveau que ne peuvent pas forcément se permettre des boites comme Sensio ou Zend parce qu'elles ont des impératifs commerciaux et des budgets restreints en matière de R&D alors que l'université permet à HyWan de disposer de ressources techniques et intellectuelles assez différentes.

Je suis surpris de voir que Cyrano a bien résumé ma pensée =D>.
Quand tu utilises des bibliothèques, tu ne fais pas la même chose (pas de la même manière) que si tu avais un framework full-stack (y clique, y installe). Tu es bien d'accord avec ça non ? Je veux m'assurer qu'on soit d'accord sur les trucs de base avant de comprendre où est le problème.

Et pour informations, on écrit Hoa (et non pas HoA) et Hoathis (et non pas HoaThis). En passant .

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 .

c'est ce que me disait mon prof d'info lorsque, lors d'une soutenance de licence) j'ai tenté de parler du bus PCI et de ces spécifications et que j'ai perdu tous le monde, parce que largeur de bus de données, d'adresse, les possibilités de passer de 32 à 64 bits qui existent depuis longtemps etc etc ben c'est un buvable pour un mec qui enseigne la propagation des ondes


donc en gros dans la "littérature" tu explique comment fonctionne piston et vilbrequib mais comment manier le volant et les pédales, alors que tu l'indique le but est justement de ne pas trop se soucier de savoir comment tu a fait comment nous on va faire.

J'attend donc la rédaction final de la doc pour comprendre une utilité à Hoa, tous comme j'essai de comprendre pour j'utiliserais zf ou symphony et juste des bibliothèque provenant de chaque (j'utilise par exemple zend_config parce qu'en 15 minutes j'ai pas trouvé comment faire proprement la surcharge des groupe (genre [truc], [re truc], [rere truuc] avec pour avec pour ancêtre truc). bon j'ai pas cherché longtemps non plus mais c'est le but d'une lib. Et quand j'aurais de quoi trouver le même type de chose avec Hoa pourquoi pas


@+

Le débat est mal situé. Il ne faut pas savoir ce qu'est Hoa mais ce qu'il apporte. Il apporte un cadre propre pour développer des bibliothèques avec tout ce que ça implique en terme d'intégration, de maintenance, de facilité de développement etc.

Par exemple, vous avez un debugger intégrer à Hoa, très pratique. Ou alors, vous pouvez créer des workers facilement (avec des stats, démarrage et arrêt à distance etc.). Ce sont pleins de petites choses que l'on découvrira au fil de la documentation. Mais ce qui m'intéresse surtout, c'est de savoir quels sont vos attentes pour vous faire découvrir ou adopter un projet, plutôt que des comparaisons à d'autres projets qui ne vont pas dans le même sens que moi (d'après mon point de vue).

Comme promis, voici deux nouveaux chapitres et un dernier en cours de rédaction (le début est déjà exploitable). Les chapitres sont : « Outils autour de Hoa » et « Aspect framework ». Des choses qui devraient vous intéresser .

Je trouve les explications toujours aussi fumeuses, que ça soit dans la doc ou ici, un ensemble de bibliothèques, ou un framework, la seule explication que je pourrais accepter c'est que les bibliothèques soient systématiquement standalone, c'est à dire qu'il n'y ai pas d'interdépendances entre les différentes classes, ce qui n'est (heureusement) le cas d'aucun framework, hoa y compris...

Je rejoins Nagol pour les "explications toujours aussi fumeuses", et c'est pas pour faire mon bébé mal nourri.
J'ai l'impression de lire un catalogue commercial et non une documentation technique...
Je précise tout de même que le projet m'intéresse fortement et que je testerai quand je trouverai un peu de temps, et je me forcerai peut être à aller relire ces pâtés pour dénicher les informations pour débuter.

Bah dites moi ce qui bloque et je le corrige de ce pas, mais j'aimerais des réactions et exemples concrets.

Avant de commencer je tiens à noter que pour un framework qui se dit respecter une liste de standards longue comme le bras avoir des erreurs d'encodages sur sa doc (restreinte qui plus est), ça fait tâche.

Je me suis mis à ZF il y a plus ou moins 15 jours donc mes commentaires en seront très marqués.
Pour commencer je ne suis pas totalement de l'avis de Nagol : Hoa est plutôt à part (entendre différent de ZF, CakePHP, CodeIgniter ou Kohana), il tire bien partie des nouveautés de PHP 5.3, ill est enfin passé sous license New BSD (ce qui n'est pas un réelle différence mais une amélioration considérable). Je trouve que l'interface de programmation est plutôt sympa, la doc en français est pas mal. Maintenant le négatif : j'ai parcouru le coda rapidement et je suis assez déçut par la méthodologie employé, je m'attarderais pas dessus mais sous ZF on a, en général, *_Interface > *_Abstract > *, dans un autre registre : la création d'un nouveau projet limite le code à /public/index.php et /application/configs/application.ini). Je trouve de plus que le code comprends certaines lourdeurs ce qui nécessiterait du refractoring ici et là, mais c'est assez léger. Je rejoins Nagol sur l'aspect marketing on sens que tu veux nous le vendre dans ta doc, il y a des mots mis en avant, etc. on sens que tu veux compenser ce manque de support engendré par la faible communauté, le problème c'est qu'on perds cet aspect didactique des versions précédentes qu'on serait en droit d'attendre d'un projet proche de la recherche et qui sont de plus présents dans la doc de ZF. Pour finir je trouve que les exemples de la doc ne sont pas assez concret pour l'internaute qui veut faire du web.
Voilà pour moi, je dois bien avouer qui si Hoa m'a ravis en passant en New BSD, j'en ai peut-être trop attenndu (ce qui n'inclus pas l'aspect professionnel présent dans ZF ou Symfony).

Bon vais tenter d'être constructif.

1) Trop de fois le mot Hoa, il y en a quasiment un par phrase, voire par demi-ligne des fois.

Le noyau est la partie indispensable de Hoa. C'est le noyau qui assure la cohésion et la modularité de Hoa. Il s'assure également de la compatibilité entre les versions de PHP et de Hoa à travers des mécanismes très simples.

Trois phrases, trois fois Hoa, c'est pas un lavage de cerveau là ?

2) Trop de répétitions du même genre : http://hoa-project.net/Literature/Learn ... ynamic_new avec "Ce mécanisme" et il y a tout un tas d'autres parties qui sont sur le même modèle avec d'autres mots. C'est très pénible à lire...

Bref pour moi ce n'est pas une documentation technique mais un acte de publicité bien caché pour détourner l'esprit du vrai but.
On n'a de cesse de se dire qu'Hoa est bien, mais pour avoir parcouru la documentation (rapidement) je me suis rendu compte que j'avais beau avoir cette impression là je ne savais pas pourquoi...

Vous êtes sûr que vous êtes pas des petits aliens venu contrôler le monde !!!

N.B : autre chose mais plus personnelle, le déroulement de la doc fait beaucoup penser aux articles du siteduzéro, et ça me choque... Je ne trouve aucunement crédible ce site pour ma part, il ne fait pas sérieux pour un sou. On fait du technique ou bien on fait de l'assistanat pour débile mentaux mais faut choisir.

@katagoto Tu parles de quelle erreur d'encodage dans la documentation au juste ?

La documentation de Hoa commence par un aperçu du noyau ce qui est plus que naturel à mon sens : comment inclure une bibliothèque, comment fonctionnent les exceptions, comment fonctionnent les événements, comment fonctionnent hoa:// etc.

Ensuite on attaque sur l'aspect framework car il est plus didactique. Là on découvre l'architecture pas à pas. D'abord Application/Public/, puis on découvre le routeur et le dispatcheur. Une fois le dispatcheur compris, on peut parler de MVC. Et là on attaque sur les contrôleurs et autre joyeusetés. Puis on apprend qu'on peut paramétrer et configurer certaines choses etc. La documentation suit une logique. Ça permet d'apprendre à utiliser Hoa comme il faut sans revenir sur des notions fondamentales.
Me tromperais-je ?

Tu dis être déçu par le code. Tu peux m'expliquer pourquoi ? C'est quoi ton histoire d'interface et d'abstract au juste ? Tu parles aussi de la création d'un projet mais je n'ai pas compris. Développe.
Tu dis que le code nécessite certains refactoring. Exemple concret ? Tu penses pouvoir comprendre le code de Hoa et toute l'abstraction qu'il présente en le parcourant rapidement en 2mn ?
Je ne veux pas vendre la documentation mais vous critiquez un peu dans le vide. J'accepte la critique si elle est constructive. Et là, je ne vois aucune construction. Si vous aimez Hoa comme vous le dites (ou que vous voulez être encourageant), alors pointez du doigt les problèmes en proposant des solutions.
Tu finis en disant que les exemples ne sont pas orientés Web parce que la documentation n'est pas terminé et que tu ne comprends pas où elle va t'emmener.