mouradski Posté(e) le 18 septembre 2010 Share Posté(e) le 18 septembre 2010 Salam, Bonjour, Je m'initie à la framwork PureMVC (pour AS3 pour mon cas) et j'ouvre cette discussion pour avoir des retours d’expériences de cette framework, des conseilles, des pièges à éviter..etc. Merci d'avance Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
Invité java Posté(e) le 25 septembre 2010 Share Posté(e) le 25 septembre 2010 l'approche PureMVC (View=Mediator+GraphicComponent, Model=BackendModel+fragments, Controller=Generaly a Command object) un pattern donc clairement orienté RIA/Évènementiel idéal pour la création de composants réutilisables (un écran qui réagit à un évènement peut être donc déclenché par n'importe quel autre composant de l'application) la mise en oeuvre est assez simple (Flex ou GWT), cependant il subsiste bien des pièges : 1. la testabilité : quel partie du code à testé 2. la fragmentation, je m'explique : prenant l'exemple d'un ecran A composé de 3 parties, P1, P2 et P3, chacune des parties est/peut aussi être considéré comme un ecran à part, et pour finir supposons que P3 est aussi composé de P(3,1), P(3,2), P(3,3), la question est la suivante : doit-on crée pour chaque partie et sous partie un Mediateur ou un seul suffira-t-il pour le traitement de toutes les parties de l'ecran A ? 3. le nommage des classes et packages 4. dans un contexte d'une équipe qui travail sur la même application, plusieurs Merges manuels sont à prévoir. 5. l'intégration graphique. Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
mouradski Posté(e) le 25 septembre 2010 Auteur Share Posté(e) le 25 septembre 2010 (modifié) ah content de te lire java 2. la fragmentation, je m'explique : prenant l'exemple d'un ecran A composé de 3 parties, P1, P2 et P3, chacune des parties est/peut aussi être considéré comme un ecran à part, et pour finir supposons que P3 est aussi composé de P(3,1), P(3,2), P(3,3), la question est la suivante : doit-on crée pour chaque partie et sous partie un Mediateur ou un seul suffira-t-il pour le traitement de toutes les parties de l'ecran A ? c'est la question qui m'est venue à l'esprit au départ, j'ai lu plusieurs approches et compréhensions de ce framework, y'en a qui regroupent les médiateurs par groupes et sont dispatchés sur plusieurs composants visuels, d'autres, et c'est l'approche que j'ai choisie, est de développer mes composants visuelles en dehors du méta paterne et des les traiter comme de simples composants, donc peu de médiateurs, je ne sais pas si c'est la meilleurs approche. Malheureusement, je n'utilise pas FLEX complètement, ie : pas de MXML et que du code AS3 , donc je pose la hiérarchie de mes composants visuelles puis j'initialise pureMVC. On n'est que deux sur le projet lol et pour l'instant ça se passe bien J'ai par contre une petite question, à quoi sert la version multi-core de la framework, j'avoue que je n'ai pas pigé grand chose à cette variante Modifié le 25 septembre 2010 par mouradski Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
Invité java Posté(e) le 25 septembre 2010 Share Posté(e) le 25 septembre 2010 multi-core c'est pour le multi-threading, Flex 3.x and lower sont mono-thread, pas de possibilité de lancer par exemple un thread pour le UI rendering et un autre pour par exemple faire du chargement de modules j'ai récemment eu l'occasion de faire du developpement Flex 3/OSGI (les modules flex sont assemblés dans des .jar et bundled pour Apache Felix). Le chargement des 14 modules de l'application prenait un temps considérable et ne cessé d'augmenter. Pour ton choix (minimisé les Mediators) ça peut être une solution mais d'après ce que j'ai constaté il faut avoir une bonne vision de l'application afin de pouvoir, très tôt, identifier les écrans ou composants (un composant n'a pas nécessairement un visuel) , un écran permettant le renseignement des informations d'un utilisateur ou d'un produit est potentiellement réutilisable et donc doit être autonome et qui plus ait, doit généralement "Roles Ready", c'est ainsi que l'on puisse avoir des écrans dont on contrôle efficacement le cycle de vie. Chez mon client, j'ai pu constaté de nombreux aspects très intéressant d'une implémentation de PureMVC (nommée photon), il est très intéressant par exemple de pensé au cycle de vie générique d'un composant (onStartup, onStop, onPause, ...) un bus d’évènements inter-modules ou inter bundle (dans le contexte d'OSGI). de toutes façons, si tu as besoin d'informations complémentaires n'hésite pas à me sollicité (par mail c'est plus simple bouadma [NOKTA] abderrazak [3nda] bigBrozer [NOKTA] KOOM Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
ychaouche Posté(e) le 22 octobre 2010 Share Posté(e) le 22 octobre 2010 l'implémentation python/wxWindows ne m'ont pas convaincu. 1 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
mouradski Posté(e) le 22 octobre 2010 Auteur Share Posté(e) le 22 octobre 2010 l'implémentation python/wxWindows ne m'ont pas convaincu. je savais pas qu'il y'avait une implémentation pour ces langages mais pour ce qui est du AS3, je peux dire que c'est de la bombe Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
Messages recommandés
Rejoindre la conversation
Vous pouvez publier maintenant et vous inscrire plus tard. Si vous avez un compte, connectez-vous maintenant pour publier avec votre compte.