Blog RIA

Si vous développez en Flex 4, il vous est sans doute déjà arrivé de vous poser des questions sur la gestion des éléments optionnels lors de la création d’un composant composite.
Par composant composite, nous entendons un composant constitué de plusieurs éléments UI de base Flex.
Par exemple, un composant composite pourrait être une boîte de login qui contiendrait 2 TextInput et 1 Button.
Dans Flex 4, ces éléments unitaires sont appelés SkinPart. Un composant composite est donc constitué de plusieurs SkinPart.

Certains composants peuvent déclarer des SkinPart optionnels. Cela signifie que la Skin associée au composant ne doit pas obligatoirement contenir un composant du même type que la SkinPart.
Par exemple, le spark Button définit la SkinPart optionnelle iconDisplay (qui est une BitmapImage). Cette SkinPart permet d’afficher une icône sur le bouton. Le développeur peut donc créer une skin sans iconDisplay s’il ne souhaite pas afficher d’icône.

L’attribut required des SkinPart est donc une fonctionnalité très intéressante dans le modèle Spark mais qui peut être limitée dans certains cas.
 

Si quelqu’un vous demande quelles sont les nouveautés du SDK 4.5, qu’allez-vous lui répondre ?

Il est évident que vous mettrez l’accent sur les fonctionnalités pour mobile ou encore sur les nouveaux composants Spark (DataGrid, Form, Image, …).
D’autres fonctionnalités ont moins été soulignées par la communauté Flex ; il nous semblait dommage de ne pas en parler.

Cet article traite ainsi des composants d’aide à la « globalization » (un terme qui regroupe l’internationalisation et la localisation) qui sont apparus dans Flex 4.5.

En soit, rien de bien neuf dans cet article mais des petits rappels sur la gestion des vues et de leurs évènements dans un contexte de projet mobile :

Dans une architecture dite « mobile » mise en place par Adobe, le conteneur principal des vues est pris en charge par l’object View.
Ces vues sont ensuite gérées de manière automatique par les objets ViewNavigator, composant de navigation standard dans une structure mobile.

La logique même de ces composants de navigation a été faite de manière à optimiser au maximum la gestion de la mémoire des périphériques en disposant peu (ou en tous cas, moins qu’une machine bureautique classique).

Plusieurs sujets de confusion sur Parsley semblent ressortir de nos missions d’audit ou de nos formations internes. Parmi ces sujets, un des plus fréquents concerne la gestion du cycle de vie des objets « managés » par Parsley en comparaison du cycle de vie des vues Flex.

La question porte particulièrement sur les architectures dont la couche de présentation est organisée autour du modèle de présentation, qui semble être devenu le pattern GUI de référence (ou presque) en Flex (en Silverlight aussi d’ailleurs, sous une dénomination différente).