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

cet article est la  de l’article suite de l’article “Le flexBoard, ou comment composer un écran de travail adapté à chaque métier“. Il aborde la technologie mise en œuvre, Flex.

Dans une application de gestion “classique”, les différentes fonctionnalités sont ordonnancées dans un certain nombre de vues, regroupées par affinités. Cependant, pour un métier donné, il est fréquent de faire appel à plus d’une fonctionnalité, l’utilisateur se retrouve donc à naviguer de vue en vue. Un alternative consiste à penser l’ensemble des “métiers” qui utiliseront notre application, et donc anticiper une redondance dans l’agencement des informations. Cela soulève deux problèmes :

• les fonctionnalités se retrouvent très liées, réel frein à la modularité.
• il est improbable d’envisager tous les métiers, en imaginant qu’ils n’évoluent pas…

Une seconde alternative, présentée ici, est de permettre à l’utilisateur d’agencer lui-même les fonctionnalités qu’il utilise au sein d’un (plusieurs) bureau virtuel. En une vue, il est alors possible de regrouper modules fonctionnels et indicateurs directs / indirects.

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 :

à partir de quelque chose comme ça :

Pour la structure… et le contenu.

A) le composant WIZDashBoardContainer.mxml

Est le composant de base utilisé dans la construction des zones d’affichage du dashboard. Il est auto-réplicatif, capable de générer de nouvelles instances de lui-même (ses enfants), sur une profondeur infinie (ce qui est inutile, mais qui peux le plus…).

Il ressemble à ça :

Sa description physique est la suivante :

Mis à part le code relatif à la gestion des icônes (orientation du layout, mesure en pixel/percent, taille de la zone…), une simple méthode sert d’ossature à la mécanique gigogne :

déclenchée par l’écouteur générique de ce composant :

B) DashTemplateEngine

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)

Dans les 2 cas, il s’agit d’un parser, d’objets physiques WIZDashBoardContainer vers DashTemplateVO, objets logiques puis en xml, et inversement, de xml en DashTemplateVO.  Pour exemple, la méthode récursive de génération depuis le xml…

Avec cette simple mécanique, il est possible de créer N’IMPORTE QUEL type de disposition : depuis le format page html de 10m de haut style rouleau de sopalin, jusqu’au modèle Flash qui occupe 100%*100% de l’écran totalement dynamique. C’est au choix.