Hello :) L'IoC c'est un peu plus compliqué car le pattern conditionne l'intégralité de l'application et pas seulement les vues. Ensuite il est tout à fait possible bien entendu de se servir d'une configuration externe IoC pour gérer au mieux les vues d'une application mais les principes d'injections de dépendances et de programmation en couches permet de garder une très grande souplesse et liberté que ne donne pas justement le MXML ou autres à mon avis...
Le simple fait que le MXML de Flex conditionne l'utilisateur sur un environnement POC très Adobe... c'est pas super open je trouve au final pour un développeur (ou même un graphiste au passage). L'IoC ne conditionne pas le code ou l'implémentation mais aide juste à mettre en relations les objets d'une application. Ensuite il est possible de donner des tas d'outils pour améliorer le principe de base mais tout en gardant à l'idée que dans tous les cas cela n'existe pas une solution qui fasse tout à la place du dév et du graphiste :) eKA+ :) Le 2 juillet 2009 11:38, _ceone <[email protected]> a écrit : > > > > Dans tous les cas.. je continue à penser que IoC + éditeur d'application > > bien pensé peut largement dépasser ce genre de solutions. > > euh question bête: un markup interprété au runtime qui sert à > instancier/configurer des composants dans une application flash c'est > pas un peu ça l'IOC ? (c'est une vraie question hein :)) > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
