La démo de ce que nous présentons se trouve à cette adresse, mais lisez peut être la suite d’abord …

Dans l’article précédent, nous avons abordé la création du modèle de bureau virtuel. (cf. FlexBoard 1/3)

Cette suite présente l’alimentation de ce dashboard en modules fonctionnels.

Pour rappel :

Le moteur de génération de “tableau de bord” utilisateur utilisé par Wizeoo s’articule autour de 3 axes  :

• le générateur de zone de positionnement, DashTemplateEngine.as, qui permettra à l’administrateur applicatif (et/ou à l’utilisateur) de définir des modèles de zones de travail.
• le générateur de contenu, DashContentEngine.as, qui permettra de disposer les modules fonctionnels (métier) disponibles/ autorisés, dans l’un des modèles de Dashboard précédemment créé.
• Le moteur de rendu, qui positionnera au runtime les bons modules aux bons emplacements.

La démo se trouve ici.

Le but est d’obtenir quelque chose comme ça :

A) le composant WIZDashBoardContentContainer.mxml

Est hérité du BorderContainer de Flex. C’est une simple zone de découpage de l’écran qui correspond au modèle défini à l’étape précédente. Il ressemble… à un rectangle tout gris, car c’est un rectangle tout gris !

En réalité, la structure présente à l’écran est gigogne, comme l’était le modèle de dashboard. Cependant, seuls les containers finaux sont visibles (en gris), la structure qui à permis leur positionnement avec précision est présence mais invisible.

Le composant WIZDashBoardContentContainer contient une méthode essentielle, qui lui permet d’accepter des enfants ‘métiers’ (des modules fonctionnels) . Ces modules sont drag’n'droppés directement dans les zones disponibles :

Il est important de comprendre ici que lors de la création du dashboard, il est IMPOSSIBLE de définir quels seront les modules métiers, qui, par définition, “modulaires”, seront greffés dynamiquement à notre application. De plus, rien n’indique que ces modules auront une structure similaire.

Afin de pouvoir les intégrer de manière générique, nous passerons donc par une interface, IDashContent, que la totalité des-dits modules implémentera :

Notez les accesseurs sur wizClass : ils permettent de définir la classe principal du module métier, views.assortment.AssortmentView par exemple, et c’est plus tard cette classe que le dashboard instanciera dynamiquement. Le dashboard, qui fait partie du noyau applicatif, est donc totalement indépendant des modules qu’il propose.

B) DashContentEngine

L’intelligence du composant se trouve dans cette classe, qui s’occupera de :

• de parser le xml pour construire l’interface (lecture)
• de définir le xml depuis l’interface (enregistrement)

Cela vous rappelle l’article précédent… Vous avez bien suivi, c’est le cas.

Pour l’exemple, la figuration du contenu depuis le xml est aussi simple, que cela :

Où la méthode generateFromXml ressemble beaucoup à la méthode receiveDrag présentée ci-avant…

Le résultat est le suivant :

C) Quelques précisions

Pour utiliser cette mécanique, il est nécessaire :

- de définir CORRECTEMENT les modules fonctionnels qui seront associés au noyau applicatif : chaque module doit amener sont descriptif remplissant le contrat d’interface IDashContent, par exemple :

<node>
<id>PIE_CHART</id>
<layoutId>LEFT</layoutId>
<wizScreen>assets/mods/PieChart.png</wizScreen>
<wizModuleName>Pie Chart on cells A1:F1,A6:F6</wizModuleName>
<wizClass>views.contents.PieChartView</wizClass>
<height>250</height>
<width>300</width>
</node>

- de respecter quelques règles de développement lors de la création des modules :

• absence TOTALE de liens directs entre modules (cela ne veux pas dire qu’il ne peuvent pas communiquer, mais que s’ils le font c’est par une interface normalisée)
• indépendance et autonomie des modèles métier des modules
• définition RIGOUREUSE des objets d’entrée et de sortie des modules