ca existe depuis longtemps mais je le mentionne ici comme le projet est open source http://code.google.com/p/flexcairngorm/
en gros des extensions pour le framework cairngorm j'ai pas regardé plus dans le detail que ca mais ca peut etre interessant a regarder avec cette logique "ok cairngorm est un debut de framework, comment des gens qui l'utilisent tous les jours peuvent l'etendre ?" et pour ca, ce projet est un bon exemple. et maintenant j'y vais de mon petit (bon ok gros) rant <rant> recemment j'ai bossé sur un projet qui utilise pureMVC meme concept juste un framework different sauf que voila là je vois bien la grosse faille ce genre de framework (et oui ca peut s'appliquer aussi a cairngorm) quand on utilise ce genre de framework, idealement c'est pour architecturer une application avec pour but - que n'importe qui dans la team bosse sur la meme structure - que une nouvelle personne arrivant sur le projet, parce qu'il connait deja l'architecture, puisse facilement d'adapter au code source et le comprendre mon premier grief contre pureMVC c'est le changement du vocabulaire le "model" devient un "proxy" la "view" devient un "mediator" le "controller" devient une "command" ca, désolé, c'est tres tres tres mauvais alors oui on peut me dire "mais meme si tu utilises un 'proxy' en vrai le proxy passe par un singleton interne 'model' blah blah blah" alors deja rien que le coup du "singleton interne" c'est une ENORME connerie, par definition un singleton ne peut pas etre interne, point ligne, y a meme pas a discuter (ou alors on peut discuter mais franchement bon courage pour me justifier ces singletons interne, car y en a pas 1 mais 3). Mon second grief envers pureMVC c'est que si idealement ca pourrait marcher dans la realité c'est tres different et en general ca tourne vite au bordel le framework force une architecture, ok mais les devs vont se baser sur ca pour developer le reste de leur code, seulement voila si ils plantent leur implementation et bah ils peuvent utiliser tout framework ou architecture qu'ils veullent leur code devient completement ingerable le fait d'utiliser pureMVC (ou autre framework) ne garantie pas une bonne architecture du code et en fait parce que les gens utilisent pureMVC (ou autre) ils pensent que par defaut quoiqu'il arrive que leur architecture de code est bonne, bah non pas forcément. exemple: ouais faisons un font-manager, youpihou on est dans pureMVC donc on va forcement bien le faire... bah non, quand on voit une class FontManager qui ne se base pas sur un model (ou proxy dans le cas de pureMVC), moi je dis "faute grave". le bon usage d'un framework comme pureMVC (ou autre) necessite des gens qui comprennent ce qu'ils font, pureMVC ce n'est que un tout petit point de depart, si on foire les regles et/ou la structure boom la jolie architecture s'ecroule. mon 3eme grief envers pureMVC c'est les notifications au lieu des events ah la celle la franchement c'est beau alors oui on peut me sortir "mais t'es pas obligé d'utiliser les notifications, tu peux n'utiliser que les events" ce a quoi je reponds "oui mais si un pignouf qui pense maitriser son code me fait un gros mixte cauchemardesque d'events mixés avec des notifications, on fait quoi ?" donc le probleme n'est pas vraiment qu'il y ait des notifications qui peuvent etre utilisées a la place des events ou switcher par des events, le probleme c'est qu'il y ait le choix le choix pour un dev experimenté c'est pas un probleme, mais pour un dev moins ou pas experimenté ca donne de grosses grosses boulettes dans le code, et a nouveau boom la jolie architecturee s'ecroule Et la le gros probleme c'est que aussi pourri soit l'implemenation du code au dessus de pureMVC les gars diront "oui mais c'est basé sur pureMVC donc est forcément bon" (en gros ils comprennent pas qu'ils utilisent tres tres mal l'architecture du truc) Mon grief final c'est le test du code source, normalement avec une bonne architecture ou micro-architecture, n'importe, ca devrait aussi aider a faire des unit tests plus facilement et plus structuré "youpi mon model est séparé donc je peux unit tester que le model, a part de la view et du controller" et bien non, je vois pas mal de gens bourrer le crane a d'autres sur "il faut utiliser pureMVC blah blah" mais je ne vois pas un seul unit test dans les parrages donc en conclusion du pureMVC mal utilisé + pas de tests ca donne un enorme bordel qui en fait crée plus de probleme que si pureMVC n'etait pas utilisé du tout. Donc la grosse faille de pureMVC, c'est que parce que une team utilise pureMVC ils en oublient completement la base du design de code (POO, et tout le toutim) parce qu'ils se focus tellement a essayer de suivre l'architecture de pureMVC qu'ils en oublie de juste bien structurer et ecrire leurs classes, mais comme ils se basent sur pureMVC ils pensent que rien qu'a cause de ca leur code est bien structuré. Ou pour le mettre dans un autre contexte, qlqn peut etre dans Java et ne pas faire de POO. </rant> zwetan --~--~---------~--~----~------------~-------~--~----~ Vous avez reçu ce message, car vous êtes abonné au groupe Groupe "FCNG" de Google Groupes. Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse [email protected] Pour résilier votre abonnement à ce groupe, envoyez un e-mail à l'adresse [EMAIL PROTECTED] Pour afficher d'autres options, visitez ce groupe à l'adresse http://groups.google.com/group/FCNG?hl=fr -~----------~----~----~----~------~----~------~--~---
