La problématique des productions Flash multi fichiers

Lors du développement d’un site Flash à fichiers multiples, une problématique apparait très rapidement dans le processus de développement : La réutilisation des même éléments (graphiques, classes, composants) dans plusieurs des fichiers du site. Le problème vient entre autre du fait que chaque fichier  SWF a une librairie de graphique, composant, et classes unique. De ce fait, si on veut utiliser le même graphique dans deux fichiers SWF, ont doit donc recopier les mêmes éléments qu’on désire réutilisable dans toutes les librairies nécessaires. Cela implique une redondance des éléments et donc une multiplication du poids des fichiers.

Avant  l’arrivé de Flash CS4 et de l’ActionScript 3, il n’y avait pas beaucoup de solution pour contourner le problème. Ont pouvait utiliser un fichier exclude.xml au même endroit que notre fichier FLA pour définir les classes qui ne devait pas être compilé  dans le fichier SWF. Ainsi on pouvait exclure les classes qui étaient dupliqué à travers plusieurs fichiers SWF de l’application. Le problème était qu’on devait quand même recopier les éléments graphiques dans chacun des ces fichiers FLA pour ne pas avoir des erreurs de compilation sur des éléments inexistant dans la librairie.

Les modules

Depuis la sortie de la suite CS4, il est maintenant possible d’intégrer des librairies externes pour la compilation directement à partir de l’IDE de Flash. Il est donc maintenant possible de créer une librairie d’élément (graphique, composant, classes) qu’on désirer partager à travers plusieurs fichiers mais qui ne seront pas compiler (injecter) dans le fichier final d’un SWF donné. L’arrivée des modules élimine donc la redondance de poids avec la réplication des éléments partagés dans plusieurs librairies des fichiers FLA.

Pour créer une application multi fichiers avec module, ont doit donc commencer par créer le module en tant que tel et ensuite ce module est charger en premier par le fichier principal (celui qui s’occupe du chargement des fichiers subséquents) et ensuite procède au chargement des sections ou sous-section de l’application. Dès que le module est chargé, les sections et sous-sections ont directement accès aux ressources de celui-ci. Le module doit cependant être chargé de façon à ce que « l’Application Domain » soit le même que le fichier principale pour que les ressources soient accessible.

Création d’un module
Le module se crée en deux étapes. En premier lieu, on crée un fichier FLA et on y place tous les éléments réutilisables que nous voulons partager à travers les différents fichiers SWF du site ou de l’application. Ensuite, nous exportons le tout en format SWC (fichier SWF compressé par ZIP) et SWF. À partir de cet instant, le module est donc terminer et prêt à être utiliser directement dans les autres fichiers.

Exemple de création

• On crée un fichier “module.fla” dans lequel on inclut tout les éléments (graphiques, composants, classes, etc...) à partager
• On exporte ce fichier en “module.swc”
• On compile ce fichier en ”module.swf”
• Pour tous les fichiers FLA qui doivent utiliser ces éléments, inclure le SWC dans les paramètres de publication sous l’onglet “External Library Path”
• Dans votre fichier principal, charger le fichier “module.swf” en premier lieu, et ensuite procéder au chargement des sections et sous-section selon le besoin

En mode développement, on peut bien tester les sections et sous-sections en chargeant directement le module dans ces fichiers avant toute exécution du code pour pouvoir bien tester les fonctionnalités. Lors de la mise en ligne, on retire tout simplement le chargement du module dans les sections et sous-sections. C'est présentement la meilleure solution pour le travail en multi fichiers.

Vers la fin des années 90, les système de gestion de contenu ont débuté leur ascension vers la popularité pour tous les sites de petite et moyenne envergure. Les boîtes de production interactive voulaient vendre des sites clef en main. Pour que le client puisse ainsi gérer entièrement sont site comme bon lui semble. Nous avons donc vu au cours des 15 dernières années, dans le cadre de notre travail, des système de gestion de contenu mal fait qui rendait le travail de mise à jours des sites ardu et pénible, et d'autre qui au contraire répondait très bien aux besoins mais qui avec la progression des technologies (intégration Web valide, sémantique, dynamisation avec JavaScript, réseaux sociaux) sont maintenant désuets. Nous avons ensuite vu l'émergence des système de gestion de contenu "libre de droit" (Typo3, Drupal, DotNetNuke, etc.) en grand nombre pour le  bonheur des clients moins fortunés. Une solution viable, solide, et robuste (tout dépendant du gestionnaire choisi) à la porté de tous ou presque.

Qu'en est-il maintenant des système de gestion de contenu ? En tant que client ou personne ayant besoin des fonctions d'un système de gestion de contenu, comment choisir la meilleure option pour nos besoin ? Est-ce que le client a réellement besoin d'un système de gestion de contenu ? Est-ce vraiment la meilleur solution pour mon site / application ? La réponse devrait être simple mais malheureusement elle ne l'est pas. Il n'existe aucune réponse parfaite qui saura répondre à tout les besoins que ce soit d'un système de gestion de contenu hyper simple au plus complexe. Pour faire un choix éclairé et qui correspond vraiment à nos besoins, je crois qu'il est important de décrire exactement les options qui s'offrent à un client pour les choix de développement d'un site ou d'une application avec système de gestion de contenu.

Il n'existe malheureusement aucune réponse généralisée qui permet de choisir une solution spécifique qui répondra à tous les cas de figures. À chaque projet sa solution. La meilleure option pour un projet donnée n'est pas nécessairement souhaitable pour un autre projet.

Développement sur mesure
Il est parfois souhaitable dans certain cas de figure, d'y aller d'une solution complètement sur mesure. On prend bien note des besoins de gestion de contenu du client et on implémente un système de gestion de contenu qui réponds exactement à ces besoins. Cette solution est optimale dans le cas de projet spécial qui nécessite une grande liberté au niveau de la logique de site ou d'application ainsi qu'au niveau graphique. L'utilisation plus ou moins intensive de "Flash" dans un site ou une application implique souvent le développement sur mesure d'un système de gestion de contenu car les système existant (pas tous mais la majorité) ont de la difficulté à bien gérer le "Flash".

Avantage

• Grande liberté au niveau de la conception de l'application et du graphisme.
• Permet d'intégrer des fonctionnalités plus complexes sans contourner un système limitatif.
• Meilleure gestion de l'intégration des fonctionnalités des réseaux sociaux (Twitter, Facebook, etc.)
• Le système peut être mieux prévu pour une future expansion des fonctionnalités.
• Permet d'optimiser les performances du site ou de l'application de façon spécifique.
• Gestion optimale de la sécurité de l'application (selon le niveau requis)

Inconvénient

• Temps et coûts de développement majoritairement plus élevés.
• Système fermé et donc connu seulement du développeur ou de l'entreprise réalisant le projet (peut devenir problématique si les personnes responsables ne sont plus disponibles pour l'expansion du système).
• On réinvente la roue pour la majorité des fonctionnalités déjà écrite et utilisé par des milliers d'utilisateurs.

Développement sur mesure avec "framework"
On utilise exactement la même démarche mentionné dans le développement sur mesure mais cette fois-ci au lieu d'effectuer le développement avec ses propres librairies, on utilise des "framework" préférablement "libre de droit" (Code Igniter, CakePHP, Django, Rails) comme base au développement du système de gestion de contenu. Ainsi, selon le "framework" utilisé on ne s'oblige pas a réinventer la roue pour développer les opérations de base d'un site ou d'une application Web.

Avantage

• Grande liberté au niveau de la conception de l'application et du graphisme.
• Permet d'intégrer des fonctionnalités plus complexes sans contourner un système limitatif.
• Meilleure gestion de l'intégration des fonctionnalités des réseaux sociaux (Twitter, Facebook, etc.)
• Tirer profit d'une base d'usager ayant développé des fonctions similaires avec le même "framework".
• Permet au client de passer le flambeau du développement à d'autre développeur ou entreprise qui maîtrise ce "framework".
• Permet d'optimiser les performances du site ou de l'application de façon spécifique avec les outils du "framework".
• Gestion optimale de la sécurité de l'application (selon le niveau requis)

Inconvénient

• Temps et coûts de développement majoritairement plus élevés.
• Système semi-fermé qui contient une bonne partie de développement effectué par le développeur ou l'entreprise qui  a produit le site ou l'application.
• On réinvente la roue pour une partie des fonctionnalités déjà écrite et utilisé par des milliers d'utilisateurs.

Système de gestion de contenu propriétaire
Développer par des entreprises ou des développeurs (Expression Engine, K3 Soft) qui veulent généraliser les opérations courantes d'un système de gestion de contenu et ensuite revendre leur solution pour tirer profit de leur temps de développement et ainsi offrir des solutions clé en mains. Ces solutions répondent aux besoins typiques généralisés pour la pluspart des applications ou site : gestion des pages, gestion du contenu textuel, gestion des menus, gestions des éléments médias, gestions du style graphique des pages, forum, envoie de courriel de masse, wiki, blog, etc... Les prix vont souvent varier selon l'entreprise et les fonctions requisent.

Avantage

• Prêt à utiliser directement après l'installation / configuration.
• Facilite les opérations de gestion de contenu typique.
• Support de l'entreprise pour l'utilisation et les problèmes avec le produit.
• Temps de développement et coût réduit, seulement l'intégration du graphisme est à faire.

Inconvénient

• Selon les systèmes de gestion de contenu, il y a limitation au niveau graphique pour respecter les guides du système.
• Selon le système, difficile voir impossible d'implémenter des fonctionnalités qui sortent des généralités implémenter par celui-ci. (lorsque c'est possible, devient souvent plus long à implémenter que pour une solution sur mesure).
• Compte tenu du nombre de personnes qui supporte le développement du système, tendance à être désuet après 1 ou 2 années.
• Difficile d'optimiser les performances de l'application ou du site si le site ou l'application éprouve des problèmes de performances.
• Outre l'entreprise ou le développeur vendeur du système, personne ne connait le système en place. (peut devenir problématique si les personnes responsables ne sont plus disponibles pour l'expansion du système).
• Gestion souvent inexistante des fonctionnalités des réseaux sociaux (Twitter, Facebook, etc.).

Système de gestion de contenu "libre de droits"
Ces systèmes utilisent exactement la même approche qu'au point précédant mais cette fois-ci le développement est effectué par la communauté. Ont applique encore une fois une généralisation des fonctionnalités requisent par un système de gestion de contenu . Les systèmes sont donc développer par des milliers de développeur qui tente au fil du temps de développer le meilleur système possible.

Avantage

• Prêt à utiliser directement après l'installation / configuration.
• Facilite les opérations de gestion de contenu typique.
• Tirer profit d'une base d'usager utilisant déjà ce système, une communauté active autour du produit.
• Permet au client de passer le flambeau du développement à d'autre développeur ou entreprise qui maîtrise ce système de gestion de contenu.
• Temps de développement et coût réduit, seulement l'intégration du graphisme est à faire.
• Tirer profit des extensions du système développé par la communauté pour des fonctionnalités qui sortent du cadre générique du système de gestion de contenu.
• Système testé par des milliers d'utilisateurs ce qui donne majoritairement un produit robuste et stable.

Inconvénient

• Selon les systèmes de gestion de contenu, il y a limitation au niveau graphique pour respecter les guides du système.
• Selon le système, il est légèrement plus long d'implémenter des fonctionnalités qui sortent des généralités implémenté par celui-ci. (lorsque cette fonctionnalité n'est pas disponible dans la communauté).
• Difficile d'optimiser les performances de l'application ou du site si le site ou l'application éprouve des problèmes de performances.
• Gestion souvent inexistante des fonctionnalités des réseaux sociaux (Twitter, Facebook, etc.). Il y a cependant amélioration de ce côté.

Chacune des solutions comporte ses avantages et ses inconvénients. Il est donc important d'évaluer la meilleure solution en tenant compte premièrement du budget pour le site ou l'application, et ensuite déterminer exactement les fonctionnalités requises. Ensuite, une personne qualifiée pourra vous diriger dans la bonne voie pour tirer maximum à court et long terme de votre solution. Il n'existe pas de solution parfaite, seulement des solutions adaptées.