tombé sur ca un peu par hasard mais pas mal de tres bonnes infos
http://weblogs.macromedia.com/paulw/archives/2007/09/presentation_pa.html
une analyse et explication de differentes manieres de gerer une UI
(presentation)
et cerise sur le gateau il double les articles en analysant comment
une structure UI
peut etre unit testé
introduction a l'unit test d'interfaces
http://weblogs.macromedia.com/paulw/archives/2008/03/unit_testing_us.html
Autonomous View
http://weblogs.macromedia.com/paulw/archives/2007/09/presentation_pa_1.cfm
http://weblogs.macromedia.com/paulw/archives/2008/09/unit_testing_us_3.html
Supervising Presenter
http://weblogs.macromedia.com/paulw/archives/2007/10/presentation_pa_2.cfm
http://weblogs.macromedia.com/paulw/archives/2008/05/unit_testing_us_2.html
Presentation Model
http://weblogs.macromedia.com/paulw/archives/2007/10/presentation_pa_3.cfm
http://weblogs.macromedia.com/paulw/archives/2008/04/unit_testing_us_1.html
View Helper
http://weblogs.macromedia.com/paulw/archives/2007/11/presentation_pa_4.cfm
Code Behind
http://weblogs.macromedia.com/paulw/archives/2007/11/presentation_pa_5.cfm
Passive View
http://weblogs.macromedia.com/paulw/archives/2007/11/presentation_pa_6.cfm
ses conclusions
http://weblogs.macromedia.com/paulw/archives/2008/02/presentation_pa_7.html
perso j'aime bien le code behind meme si ce n'est pas l'ideal
et idealement j'ai une petite recherche en aparté pour mettre au point
un system de Visual Proxy (qui marchait tres tres bien avec AS1/AS2)
et qui justement resouds le probleme de ne pas devoir heriter
entre la view et le model de la structures code behind, et aussi
avec une petite touche de Newton (system d'UI pour le Apple Newton
qu'on peut trouver documenté sur le net)
Ces derniers mois j'ai pu mettre les mains dans du tres tres tres gros
code Flex
(30 devs, plus gros projet mondial fait en Flex avec Adobe Consulting,
si si :p)
bref avec ce genre de gros code on voit tres vite les limitations de
Flex:
- le mxml c'est facile, et facile a abuser
- le mxml c'est comme une class AS3 ce qui peut etre tres bien
mais aussi tres mal
ex de chaine heritage: mxml <-- as3 <-- mxml <-- as3 etc.
- les styles c'est un gros bordel
quand on doit definir un nom de style pour quelques 3000 classes
- utiliser du mxml cela favorise les memory leaks
et pas des petits, des enormes de enorme
genre si vous utilisez les mx.charts et bah en fait les memory leaks
n'ont été patchés que dans le Flex SDK 3.2.0
- mettez des devs venant du Java dans Flex et ils font du Java pas de
l'AS3
autres limitations
- Flex avec une 10aines de gros components et une application
principale énorme
ca donne 1mn+ a se charger au depart
- ca donne aussi un eclipse qui explose si on ne fait que caresser le
design view
- ca donne de tres tres gros temps de compilation
si ca interesse, pour etre vraiment rapide
- ne pas utiliser Flex Builder pour compiler, utiliser direct Ant
- utiliser du pure AS3 et bannir le mxml
- regulierement profiler l'appli des la 1ere ligne de code
du moins pour toute la partie "shell" (comme au bon vieux temps de AS1
et/ou CD-Rom)
cad on fait un shell leger (~50K) qui n'a que la responsabilité de
loader et de configurer
et je finirais sur un autre point,
le pour ou contre des framework MVC,
et bien ca c'est vite réglé, que ce soit pureMVC ou Cairngorm
et bien c'est de la merde (et oui je pese mes mots)
ces frameworks tels qu'ils sont distribués sont juste bon
à faire une petite demo et/ou apprendre le MVC à une certain sauce
en réalité (tres tres tres gros projet) le framework represente a
peine
0,001% de l'architecture et doit obligatoirement etre patché (ex:
memory leaks)
ou étendu à l'extreme pour commencer a vraiment servir a quelque
chose,
et encore...
en gros je vais redire ce que je dis depuis 3 ou 4 ans :)
concentrez vous sur le langage et les features du langage
dans le cas actuel: AS3, c'est là où il y a les vraies possibilités.
zwetan
ps: j'avais pas prevu d'ecrire aussi long j ai du m emporter qlq
part :D