Bonjour tous ! (enfin, plutôt "bonjour toi" qui t'es perdu sur notre blog en cherchant un tuto sur flash)

Nos amis de Neiio nous ont récemment contacté pour un retour d'expérience au sujet d'une discutions-bière autour de notre expérience de Flex et des frameworks MVC. Pour ceux qui savent pas, les frameworks MVC c'est... ben c'est la et flex, ben... c'est la.

Si on veut rester vulgaire flex c'est un langage de programmation pour le internet en flash qui s'anime et MVC c'est une brique logicielle pour ce langage qui permet de résoudre des problématiques de... programmeur.

Tu l'as compris, seul amis qui nous reste et qui passe nous voir de temps en temps, ce topic concerne les programmeurs. Si tu veux voir la suite des bd ou autre... ben.... on a pas le temps reviens plus tard ! Allez !

Pour ceux qui restent (s'il y en a) le débat a commencé comme ça : Damien (Programmeur/graphiste/ingé/Déménageur/homme à tout faire de chez Neiio , une entreprise pleine d'avenir et de talent qui va bien de par chez nous) nous a contacté pour nous relater ses expériences plus ou moins heureuses concernant Flex  :

 

Bonjour,

Hier j’étais en journée de repos, parce que j’avais séché plusieurs jour du seigneur, et plusieurs « vacances » ; donc j’ai raté l’apéro et la discussion au sujet de « wan’agad’ a flex ».

On utilise flex et papervision pour notre site web. Apparemment vous en avez fait les frais.

Très vite je me suis rendu compte de la nécessité d’utiliser une  ‘’micro-architecture’’ parce que flex, c’est sale ! On dit micro architecture quand on est flex, en fait c’est un framework.

Avec l’âge et la sagesse je suis devenu faignant donc hors de question de recoder un MVC. Des micro-architecture MVC j’en ai déjà développé à l’âge de pierre en PHP et en C++ ; à l’époque, ou on pensait que Microsoft Fondation Class c’était top. J’ai même vu des model view sans controler de chez QT, bref. MVC j’ai fini par comprendre ce qui est bon ou mauvais à l’usage.

Ce qui est sur c’est que je connais très mal flex et que je ne peux pas vraiment affirmer que c’est sale. Tout ce que je vois c’est que si caingorm, mate, pureMVC et swiz existent c’est qu’il y a un problème. Et le problème il me semble que je l’ai touché du doigt me semble t’il.

Je regarde l’application flex de base avec le fichier MXML qui déclare dans le même fichier les toutes les vues de l’application puis les ‘’include’’ ou import, et encore un genre de fonction statique le tout mixé avec le langage de description de la fenêtre et si ce n’était pas suffisant on y ajoute un css.

WOUAOU ! j’ai commencé par séparer les fichiers MXML, puis je me suis dit c’est le controller qui va se charger de créer les fenêtres, j’instancie les fenêtre à la main et la surrrprise ! Je me rend compte que rien n’est créé a oui il faut attendre le callBack « applicationComplete » quelle horreur. Ca signifie que le controlleur doit connaitre toutes ses vues et avoir attendre tous les callback complete avant de faire quoi que ce soit. C’est à ce moment que je me suis dit qu’il était temps de faire un tour chez caingorn mate swiz et pureMVC.

Caingorm est trop vieux trop verbeux, si trois autres existe c’est qu’il y avait des problèmes, on peut le penser. Je n’aime pas les outils complexes. Si je loue une mini pelle pour creuser ma piscine ce n’est pas parce que je n’aime pas piocher c’est pour creuser en une semaine au lieu de six mois. Avec caingorm il faut d’abord passer le permis, et la pelle est tellement complexe qu’on a plus vite fait de creuser à la main.

pureMVC ça me fait penser à mon second MVC c’est tellement propre que tu passes plus de temps à laver l’application qu’a coder : entre les commandes les proxy et tout le tsoin tsoin ça me fait penser à mon second mvc c’était une horreur à utiliser. Mais c’est sur c’est vraiment un MVC, mais parfois il ne faut pas suivre les patterns à la lettre parce que c’est mal.

Secrètement j’attend un quelque chose qui ressemble à QT avec son Model View + delegate si t’en veux le tout agrémenté de signaux slot ( http://doc.trolltech.com/4.0/model-view-programming.html ). Ou encore mieux Django qui débarque avec son concept de MTV modèle template view, concept excellent ( http://fr.wikipedia.org/wiki/Django_(framework) ).

Mate je n’ai pas fini de fouiller mate donc je ne peux que saluer l’effort de documentation, mais à priori il semble verbeux à souhait. A vrai dire seul swiz me fait rêver avec son IOC inversion of control, seul problème c’est si mal documenté que je vais devoir ouvrir les classes, utiliser avec et sans swiz pour comprendre l’apport de swiz.

Ce qui est certain c’est qu’en quittant C++/QT je perd les signal/slot (propager des callback dans une application) et pas mal de choses comme la possibilité de bien contrôler l’instanciation des objets.En fin de compte je me demande quelle est la productivité à laquelle je peux m’attendre avec flex et action script versus celle à laquelle j’aurais pu m’attendre avec C++. J’ai un peu l’impression que flex pousse le développeur à faire du sale. Qu’en est-il en vrai ? C’est aussi une question de débutant qui n’a pas encore lu la doc et qui s’est plongé dans le code. Je reviendrais donner un vrai avis après 3 à 6 mois de développement et je pourrais dans ce cas affirmer c’est SALE ou c’est PROPRE !

En attendant je demande l’avis de la communauté, mais quand on gratte juste la surface à priori ça n’a pas l’air propre. Faites moi plaisir dites-moi que je me trompe…

Voici un bon article sur les framework autour de flex http://www.insideria.com/2008/12/frameworkquest-2008-introducti.html

Et plus généralement j’ai eu à me poser la même question pour c++ php ou python

Et j’ai retenu QT pour C++ un genre de rolls…

Ez-component et zend framework pour php, et django pour python. Pour finir en matière d’architecture django et Qt forcent vraiment le respect. Et peut être un jour si je sors un framework les gens pourrons critiquer mon kungfu de mon vivant. Et parpevision , rien à dire

Cordialement Damien MIRAS


 

Par chez nous, chez Klakos , entreprise pleine d'avenir vu qu'elle n'a pas encore de passé, on a aussi travaillé sur des solutions techniques Flex, et, tenez vous bien, A BASE DE FRAMEWORK MVC ! Si si !... Mais on a laissé tomber. On préfère la plage. Non... je rigole. On a préféré s'orienter vers un autre type de développement avec du client lourd. Les raisons ? Je vous les expose ici !

Ma réponse, donc :

      Personnellement je n'ai rien à redire concernant Flex. Je le trouve simple et efficace, même s'il faut un peu de temps pour s'acclimater aux classes, le plus contraignant étant la recherche de documentation concernant les différentes versions du MXML, mais ça se trouve. En revanche l'ActionScript est parfaitement documenté et abordable, et avec un peu de rigueur il est possible de maintenir une application faite en flex, mais ça demande de découper l'application en micro-fonctionnalités en amont, en faire des classes et les réintroduire dans l'ensemble. C'est vrai qu'a ce niveau certains choix d'adobe peuvent laisser rêveur (cf leur implémentation du pattern "Interface" en "dur" au détriment de l'héritage multiple....ca m'a fait bizarre, j'avoue ) mais dans l'ensemble il est possible de faire avec si on ne recherche pas les performances absolues. Les raisons pour lesquelles nous avons finalement écarté l'utilisation de Flex pour le prototypage ne sont pas du tout liées à Flex mais résident surtout dans le manque de bibliothèques et de frameworks intégrés permettant la gestion (d'assets, notamment) en local, mais pas du tout en matière de productivité. On a bien pensé à générer une application AIR à partir de PureMVC mais cela n'a pas suffit, surtout concernant les animations, le pré-caching des effets spéciaux, la gestion des évènements sonores, j'en passe et des meilleures...

Concernant PureMVC il faut quelques jours pour s'y acclimater, mais c'est un framework extrêmement intéressant, pour peu qu'on y passe le temps de prise en main nécessaire. C'est vrai qu'il peu paraitre obscur au premier abord mais à l'utilisation y'a pas photo ; meilleure stabilité de l'application, complexité constante pour une application à grande échelle, et au final gain de productivité indéniable. Cela dit pour réellement avoir l'utilité d'un tel framework il faut une appli vraiment grosse qui tend à la complexité. Inutile d'utiliser PureMVC pour une application de moins de 1.000 lignes de code qui n'est pas censée gérer la persistance de ses données (ça reste mon avis).

    Concernant Papervision, la encore c'est à mon avis la meilleure offre concernant les moteurs 3D qu'on peut trouver en Flex/RIA. Les classes sont claires, certains outils sont disponibles, la licence n'a pas l'air contraignante et la communauté est bien réactive. Côté performances c'est aussi le meilleurs d'après moi, même s'il n'existe pas encore (enfin, à l'heure ou nous l'avons utilisé) de solutions ayant intégré la techno de flash 10. D'après Adobe, flash 10 intègre les pipelines des cartes accélératrices 3D... d'après les tests que j'en ai vu, flash 10 n'intègre que quelques-une de ces fonctionnalités, il manque encore le Shading et énormément des capacités d'éclairage des cartes actuelles... a voir si Adobe effectue l'intégration au fur et à mesure, ça peut être intéressant mais il faudrait que Papervision sur le coup intègre ces nouvelles fonctionnalités, ce qui doit demander un gros effort de remaniement du code bas niveau. J'ajouterais à ça que niveau productivité concernant Papervision j'ai été un peu dérouté au premier abord par leur outil intégré à Flash. Je conseille de ne pas l'utiliser et de tout faire en flex, les librairies sont suffisamment claires si on a l'habitude des moteurs 3d c'est un jeu d'enfant, mais la je dérive...

    Donc pour résumer ; oui, ce sont effectivement des outils qui permettent un énorme gain de productivité passé la phase de prise en main (qui est somme toutes assez rapide). Après... comparer une solution C++ à une solution RIA est toujours un peu délicat, mais je répondrais que le RIA est toujours plus intéressant en terme de rapidité de mise en œuvre lorsque les performances ne sont pas importantes et lorsqu'on veut s'affranchir de la problématique de la plateforme. Ça deviens vraiment épineux lorsqu'il s'agit d'applications 3D, étant donné que ces applications sont énormément demandeuses en terme de performances, proches du matériel (et donc du système d'exploitation) et demandeuses d'un set d'outils parallèles très large (suites de modélisation, animation, etc...)...Si la priorité est la mise en place sans trop regarder le niveau de technicité alors il vaut mieux une application RIA. En revanche, si la priorité concerne la complexité de l'affichage et des scènes, les effets de lumière, l'empreinte mémoire et la charge processeur, alors la, du coup, vaut mieux client lourd, et donc solution C/C++.

Mais dans ce dernier cas, a mon avis, c'est toujours beaucoup plus cher !


J'ai essayé de donner le plus de précisions, maintenant, si toi, passant du net programmeur a tes heures ou professionnel, tu trouve quelque chose à dire ou un retour d'expérience à offrir à Damien (et à moi par la même occasion) tu es ouailcôme (oui, je sais c'est pas comme ca que tu t'appelles et j'ai un humour de merde... c'est comme ça).

Donc voila...