> C'est vrai mais un peu sévère je trouve.
j'ai mis ca dsnas une balise <rant> :p > Tout ce que tu dis à beaucoup de sens mais il faut bien commencer quelque > part. > Nous utilisons pureMVC dans tout nos projets. pureMVC en soi n'a rien de > transcendant mais il force à architecturer là ou d'autre oublierai même > l'idée de réfléchir avant de coder. > je critique pas ceux qui utilisent pureMVC en general je critique les gens qui l'utilisent mal si on pousse les choses loin, pour la meme application qu'on soit avec pureMVC, cairngorm ou autre on obtiendra qlqch de sensiblement pareil (meme si les architectures ne sont pas exactement pareil) > Le changement de vocabulaire ne me semble pas être un problème non plus. > Les notifications sont un moyen de communiquer entre le modèle et la vue, ni > plus ni moins. > Les events vont simplement servir dans chaque composant. Je trouve au > contraire que cela clarifie grandement le problème. > disons que ca jecritique plus dans le sens "ne pas changer l'interface" par ex: si pendant des annés je suis habitué a faire "svn checkout" passer a "hg clone" ca me change mon vocabulaire donc autant je suis pour que les gens changent facilement de logiciels et leur habitudes pour explorer des choses differentes autant je suis contre changer le vocabulaire pour une tache identique file/save file/save as etc. si on le change en document/write document/write as c'est mauvais amha bref je critique dans ce sens là [...] > > Pour les singleton "interne", il n'ont d'interne que le fait d'être > instancier dans la face. J'avoue que je comprends pas. Cela me semble > parfaitement intégré au concept de facade. > voir la reponse d'eka où je suis a 200% d'accord le coup de tomber sur une ApplicationFacade qui etends Facade et qui en prime implemente a nouveau IFacade lol je l'ai vu presque tout le temps pire, si moi je pars de zero et que je fais ce que suggere eka cad definir un singleton qui instancie Facade je me retrouve en face de qlqs devs qui me sortent (yeux exorbités etc.) que je respecte pas le "best practice blah blah fucking blah" et j'ai meme vu des cas extreme où si on definit une prop "instance" pour le singleton au lieu de faire le classique "getInstance()" limite on me sortait que je faisais un hack bref, juste pour dire que bcp de gens boivent du code sans le comprendre et essayent encore moins de l'ameliorer et/ou le rendre plus pratique c'est pour ca qu on se retrouve avec des trucs du genre class FoobarFacade extends Facade implements IFacade le gars qui cree cette classe ne comprends pas le principe de facade et ne comprends pas si Facade implement deja IFacade, il a pas besoin de re-implementer a nouveau IFacade, et ca c'est grave que le gars veulle faire un getInstance() ca me gene pas plus que ca, meme si je pense que faire une public const FoobarFacade:Facade = new Facade() est plus elegant et pratique etc.. mais le coup du implements IFacade là je me dis que le gars a copier/coller du code sans le piger > Après effectivement, ce ne sont que des outils, et il est nécessaire d'y > apporter sa propre touche, de bien comprendre la logique tout en gardant à > l'esprit que c'est nous qui codons et pas le créateurs du framework. > Cela doit également correspondre à un besoin. Lorsque l'on code dans une > équipe avec des gens de différents niveau, que l'on s'adresse à des > freelance ponctuellement, et que l'on a pas sous la main un tueur de ton > envergure :) on doit se débrouillé. pureMVC ou autre framework maitrisé > permet d'avoir une logique de développement dans une société. > lol je suis pas si tueur que ca mais je connais un ou deux trucs - je sais que hors-framework le fait de bien designer son code OO interfaces, responsabilités de classes, etc. ca marche - je sais que utiliser des unit tests des le depart et continuer a tester au maximum ca marche donc ok je comprends tres bien pourquoi des gens veullent utiliser des framework architecturaux, travaille en euipe etc. pas de soucis, mais désolé pas au détriment des 2 points au dessus je peux pas encore en parlé officiellement mais vers novembre/decembre je ponderais avec eka :) des articles en detail sur la logique du pourquoi/comment un API (et pas un petit :p) a été codé de telle manière et pas autrement, et vraiment sur certain choix entre utiliser une singleton ou instancier une class dans une factory, ce genre de choix c'est ca qui est important dans du code et ce qui peut faire foirer ou pas l'utilisation d'un framework architectural. > Lorsque le devs ont moins d'expérience cela permet facilement de leur > expliqué les problèmes de ce qu'ils ont codé et de balisé le chemin. > > Donc bien au contraire je suis à 200% pour l'utilisation de tels outils. > Cela nous a permis en interne de justifié la mise en place de réunion > technique avant le départ de projet ( ce qui n'était pas le cas avant ), de > bien baliser le développement, de mettre en place une surcouche générique > qui nous correspond mieux, chargement de fichiers de configs systématique, > écoute des notifications dans des écouteurs unique, gestion global des > requête ou chargement de fichiers data, etc.... > ok pas de soucis avec ca moi je dis juste que ce que j'ai vu en entreprise c'est un ou deux gars qui partent sur pureMVC ou autre et foire l'architecture du framework ensuite ce mixte pureMVC-framework maison se retrouve etre utilisé à la base de TOUS les projets ce qui foire presque tous les projets etc. etc. etc. où est le probleme ? - les un ou deux gars du départ - l'usage systematique du MVC pour tout et rien c'est pas dramatique mais cela montre plusieurs autres problemes bcp d'agences ou jsute des devs sont "jeune" sur l'usage de ces framework limite ils feraient mieux de ne pas utiliser de framework pour maturer un peu sur l'usage du code mon dernier exemple en date c'est une agence qui en janvier est passée à AS3 et qu'ils ont commencés a se faire un framework maison basé sur pureMVC cad ils prennent pureMVC a la base mais si ils ont besoin de charger des font dynamiquement ils passent par le ASAP framework pour le loading, puis se font un FontManager dans un package utils, pas du tout intégré dans l'architecture de pureMVC le gros probleme c'est que comme ils rament sur AS3, ils mettent cette logique a toutes les sauces sur tous leur projets qlqs mois se passent et ils ont un bon gros bordel sur les bras: les loading ne gerent pas tout, les loading ne sont pas en sync avec les MVC, etc. bref pas terrible du tout > Visiblement tu parles d'un vécu bien particulier, et je prends toujours > plaisir à lire tes coups de gueule car ils me permettent de prendre du > recul, de me poser les bonnes question ; mais il ne faut pas généralisé, et > plutôt souhaitez que les plus jeunes d'entre nous se servent de ce type > d'outil car cela professionnalise grandement notre métier. je dis pas le contraire et oui je pense que je suis tombé sur quelques cas particulier :p mais bon cela montre qd meme qu'il y a des cas où l'usage des framework est "jeune" (j'arrive pas a trouver un autre mot lol) ca me fait penser a ce que faisaient les gens pour javascript, ils vont sur un repertoire qui stock des scripts, copie/colle et essayent de tout faire marcher ensemble autre exemple: l'usage a outrance des frameworks là j'ai vu un proejt qui utilise au bas mot pureMVC, Papervision3D, ASAP library, etc. avec en plsu encore 2 ou 3 autres libs et framework (genre SWFAdress etc.) imaginer tous ces framework/libs ensemble et mal utilisés ... franchement ca fait peur :D > En c, java, ou autre language bas niveau il y a beaucoup de dev avec 10 ans > d'expérience qui ne savent pas ce que c'est qu'un modèle évenementiel, un > model, un controller, une commande ou autre. > Cela va dans le bon sens pour l'ActionScript, permet de réfléchir et de > remettre son propre code en question, et ca cela n'a pas de prix. > c'est exactement mon propos :) AS3 est plutot jeune et il y a encore pas mal d'années pour que tout ca mature: les gens, les frameworks, les solutions, etc. 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 -~----------~----~----~----~------~----~------~--~---
