Hello :)
>
> C'est vrai mais un peu sévère je trouve.
> Tout ce que tu dis à beaucoup de sens mais il faut bien commencer quelque
> part.
Je ne pense pas que Zwetan au dessus dise le contraire ;)
>
> 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.
Euh oui et non :) Car si tu commences à utiliser une lib pour du MVC
ou autre c'est bien mais ce qui est dit au dessus exprime surtout un
réalisme sur la gestion de projet et les choix d'utiliser une lib ou
pas dans un projet pour tout et n'importe quoi :)
Personnellement... on débute tous et franchement pour moi quand j'ai
commencé je voulais justement trop en faire en me basant vraiment sur
certaines implémentations.. limite à faire au final de l'antipattern
et du spaguetti code dans tous les sens ! Et finalement quand je fais
le bilan .. il y a du bon mais surtout beaucoup d'utilisation farfelue
:)
>
> 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.
Si si .. c'est un problème... Dans les design pattern un pattern proxy
c'est une chose et un pattern MVC c'est autre chose :) Maintenant
quand un modèle se nomme un "Proxy" je trouve cela au niveau design de
code à côté de la plaque. Surtout quand on voit aussi dans le code de
PureMVC des implémentations du style :
package org.puremvc.as3.patterns.facade
{
public class Facade implements IFacade
{
// ...
}
}
Et qu'ensuite je vois pratiquement 90% des pecs qui utilisent PureMVC
se créer des classes concrêtes en tapant :
package
{
public MyFacade extends Facade implement IFacade
{
// code
}
}
Si je cherche dans google un tuto ou des explications dans des blogs
sur PureMVC on tombe sur ce genre de code pas réfléchi un peu
partour.. exemple :
http://www.dehats.com/drupal/?q=node/26
A noter dans le lien au dessus du coup qu'on se demande finalement à
quoi tout cela peut bien servir ? Un exemple sur le singleton avec
getInstance.. on pourrait taper tout simplement :
1 - on sort les énumérations dans une classe à part (plus propre et
plus simple à maintenir finalement)
package example
{
public class CommandList
{
public static const APP_INIT:String = "AppInit";
public static const CREATE_BOOK:String = "createBook";
public static const GET_BOOKS:String = "getBooks";
public static const UPDATE_BOOK:String = "updateBook";
public static const DELETE_BOOK:String = "deleteBook";
public static const BOOK_SELECTED:String = "bookSelected";
public static const BOOK_DELETED:String = "bookDeleted";
}
}
Puis on crée un singleton simple avec une constante dans un package
simple sans héritage inutile.
package example
{
import example.control.*;
import org.puremvc.patterns.facade.Facade;
public const ApplicationFacade:Facade = new Facade() ;
ApplicationFacade.registerCommand( APP_INIT ,
InitAppCommand );
ApplicationFacade.registerCommand( CREATE_BOOK ,
CreateBookCommand );
ApplicationFacade.registerCommand( GET_BOOKS ,
GetBooksCommand );
ApplicationFacade.registerCommand( UPDATE_BOOK ,
UpdateBookCommand );
ApplicationFacade.registerCommand( DELETE_BOOK , DeleteBookCommand );
}
Bon là c'est qu'un exemple de simplification.. mais ensuite
franchement quand on voit ce que peuvent faire certains ... des
commandes pour tout et n'importe quoi etc.. bah finalement on sent un
manque réel de maitrise du code.
>
> EN ce qui concerne le controller, l'utilisation de commande dans un
> FrontController est plutôt une bonne pratique dans le domaine de la POO me
> semble t-il.
Pas de soucis pour le FrontController.. sauf si on l'utilise pour tout
et n'importe quoi dans l'application.
> Quand aux mediators, c'est un design pattern connu qui a la même démarche
> que les MovieClipHelpers d'autre frameworks.
>
Faut juste arrêter de donner 10 noms à un même truc à chaque fois
> En ce qui concerne les proxy, je trouve que c'est au contraire extrêmement
> bon, car encore une fois cela force à architecturer et facilite énormément
> le travail avec les devs php, asp ou autre.
> Le fait qu'il soit enregistrer dans un modèle est complètement transparent
> puisque tout passe par la facade.
>
mouep... pas certain que cela soit si simple finalement :)
> 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.
>
En fait il manque des choses ... par exemple si je te dis qu'avec un
framework IoC en + de ce framework tu implémenterai pas du tout le
code de la même manière... programmer avec un bon design de code en
inversion le contrôle de l'application, et en bossant en couches..
franchement là on pourrait dire que PureMVC serait bien utilisé..
maintenant sache que je donne mon avis sur ce que j'ai pu voir à
droite ou à gauche et cela ne veut surtout pas dire qu'il est
impossible d'utilise PureMVC correctement :) Il fait son boulot... moi
ce qui me dérange c'est d'appeler cela un framework.. mais bon ;)
> 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é.
>
Euh... mouep mais cela empeche pas d'en discuter ici pour faire bouger
les choses et pour pouvoir justement montrer qu'il est possible
d'aller encore un peu plus loin en architecture ou du moins dans la
manière d'utiliser ces outils non ? :) Sinon personne ne parle.. tout
le monde dit que c'est génial et personne n'avance pour aller vers des
outils au top :)
> 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.
>
Tout dépend de qui explique quoi je te dirais ;) Car si certains
(comme dans l'article au dessus), explique un truc mais qu'il fait des
erreurs comme le coup de reimplémenter une interface déjà
implémentée... moi je dis que forcément.. bah tu apprends beaucoup de
truc parasite et franchement faut garder du recul même si on débute.
> Donc bien au contraire je suis à 200% pour l'utilisation de tels outils.
Comme tout le monde ici ;) Reste à voir comment les utiliser ;) C'est
le problème ici :)
> 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....
>
Donc en gros vous commencer à faire ce qu'il faut et c'est tant mieux
:) Donc tout le monde parle de la même chose finalement ;)
> 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.
Oui exactement c'est un coup de gueule, le truc c'est d'essayer peut
être en lisant ce qui est écrit au dessus de chercher ce qui ne va pas
et de pas tout le temps dire que l'on est "contre un truc"... ou
autre... l'idée c'est de chercher à exprimer un avis sans rentrer
toujours dans le même débat stérile ... donc je le répète une dernière
fois.. c'est pas Cairgorm ou PureMVC qui sont en cause mais la façon
de les utiliser :)
> 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.
Bah ... les pauvres... ils ont fait quoi pendant toutes ces années ... lol
> 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.
>
>
Tu l'as dis.. là dessus on est d'accord :) De façon général.. discuter
et se prendre la tête c'est avancer :)
EKA+ :)
>
> -----Message d'origine-----
> De : [email protected] [mailto:[EMAIL PROTECTED] De la part de
> zwetan
> Envoyé : mercredi 27 août 2008 13:43
> À : FCNG
> Objet : [FCNG] flex cairgorm sur google code
>
>
> 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
-~----------~----~----~----~------~----~------~--~---
