Pour quelques tests, j’ai installé Flash Media Server (la version gratuite, quand même) sur ma machine. Seulement voilà, j’ai réussi à avoir un soucis dès le lancement de mon application, avec un code d’à peine quelques lignes.

protected function connect():void {
	var connexion:NetConnection = new NetConnection();
	connexion.connect("rtmp://localhost/vod");
}

Au lancement de mon application, j’avais l’erreur suivante :

Error #2044: AsyncErrorEvent non pris en charge : text=Error #2095: flash.net.NetConnection n’a pas été en mesure d’appeler l’élément de rappel onBWDone. error=ReferenceError: Error #1069: La propriété onBWDone est introuvable sur flash.net.NetConnection et il n’existe pas de valeur par défaut.
at Main/connect()[C:\Documents and Settings\palleas\Mes documents\flash\FlashMediaServerTest\src\Main.as:18]
at Main()[C:\Documents and Settings\palleas\Mes documents\flash\FlashMediaServerTest\src\Main.as:12]

J’ai pas mal cherché sur le net et j’ai finalement trouvé la solution en fouillant la documentation sur le site d’Adobe, elle est vraiment toute bête. On commence par spécifier la propriété “client” de l’objet NetConnexion, en lui mettant la valeur “this” :

protected function connect():void {
	var connexion:NetConnection = new NetConnection();
	connexion.client = this;
	connexion:NetConnection .connect("rtmp://localhost/vod");
}

On déclare ensuite une méthode vide nommée “onBWDone”, vu que c’est ce que cherche Flash finalement :

public function onBWDone():void {
	trace("onBWDone !");
}

Et voilà! Je démarre juste avec Flash Media Server, je poste cette astuce ici parce qu’elle m’a empêché de démarrer, je ne le ferais pas pour chaque bug que je corrige, mais plus probablement un billet plus conséquent par la suite.

Pour commencer, la “popup” affichée sera un simple composant Group, affichant une image (via le composant BitmapImage) :

<?xml version="1.0" encoding="utf-8"?>
<s:Group 	xmlns:fx="http://ns.adobe.com/mxml/2009" 
			xmlns:s="library://ns.adobe.com/flex/spark" 
			xmlns:mx="library://ns.adobe.com/flex/halo" 
			width="253" height="300">
	<s:layout>
		<s:VerticalLayout horizontalAlign="center"/></s:layout>
	<s:BitmapImage source="@Embed('assets/lolcat.jpg')" />
</s:Group>

L’application accueillant cette popup ne comprendra qu’un bouton déclenchant l’ouverture de ladite popup :

<?xml version="1.0" encoding="utf-8"?>
<s:Application xmlns:fx="http://ns.adobe.com/mxml/2009" xmlns:s="library://ns.adobe.com/flex/spark" xmlns:mx="library://ns.adobe.com/flex/halo" minWidth="1024" minHeight="768" creationComplete="init(event)">
	<fx:Script source="global.as" />
	<s:Button id="openButton" label="Open window" />
</s:Application>

Cette popup sera donc affichée lors d’un clique sur le bouton prévu. Ce fonctionnement étant mis en place en écoutant l’évènement qui va bien, et en utilisant ensuite la classe PopupManager :

import com.palleas.CustomPopup;
 
import flash.events.MouseEvent;
 
import mx.containers.TitleWindow;
import mx.events.FlexEvent;
import mx.managers.PopUpManager;
 
import spark.primitives.SimpleText;
 
public function init(e:FlexEvent):void {
	openButton.addEventListener(MouseEvent.CLICK,onOpenClick);
}
 
public function onOpenClick(e:MouseEvent):void {
	var window:CustomPopup = PopUpManager.createPopUp(this,CustomPopup,true) as CustomPopup;
	PopUpManager.centerPopUp(window);
}

Voici donc ce qui s’affichera :

Maintenant, pour que la popup se ferme lorsque l’on clique sur le modal, il suffit en réalité d’écouter le click en dehors de la popup. Sachant que le modal permet de désactiver le reste de l’interface, un clique en dehors de la popup est forcément un clique sur cette modal. Pour ce faire, il suffit d’utiliser l’évènement FlexMouseEvent (toujours dans la méthode créant la popup) :

public function onOpenClick(e:MouseEvent):void {
	var window:CustomPopup = PopUpManager.createPopUp(this,CustomPopup,true) as CustomPopup;
	PopUpManager.centerPopUp(window);
	window.addEventListener(FlexMouseEvent.MOUSE_DOWN_OUTSIDE,onModalClick);
}
 
public function onModalClick(e:FlexMouseEvent):void {
	PopUpManager.removePopUp(e.currentTarget as CustomPopup);
}

Et voilà !

DestroyTwitter est pour moi le client Twitter le plus réussi. Il propose une fonctionnalité très intérressante qui est de pouvoir prévisualiser une URL. En cliquant sur une URL dans un tweet en ayant la touche “alt” pressée, il est possible d’avoir le titre de la page pointée ainsi que l’url finale, ce qui est très pratique dans le cas d’url réduites.

Ce genre de fonctionnalité est très simple à implémenter dans une application AIR, grâce au composant URLLoader et aux évènements disponibles s’il est utilisé dans AIR, notamment HTTPStatusEvent. Pour commencer, nous allons créer une interface simpliste :

<?xml version="1.0" encoding="utf-8"?>
<s:WindowedApplication 	xmlns:fx="http://ns.adobe.com/mxml/2009" 
						xmlns:s="library://ns.adobe.com/flex/spark" 
						xmlns:mx="library://ns.adobe.com/flex/halo"
						creationComplete="init(event)">
	<fx:Script source="global.as" />
	<s:layout>
		<s:VerticalLayout paddingTop="5" paddingRight="5" paddingBottom="5" paddingLeft="5"/>
	</s:layout>
 
	<s:HGroup>
		<s:TextInput id="urlToPreview" />
		<s:Button id="previewButton" label="Preview" />
	</s:HGroup>
	<s:SimpleText id="urlFinal" />
</s:WindowedApplication>

Ensuite, il suffit de faire en sorte d’envoyer une requête vers l’URL spécifiée dans le champs de texte, d’écouter l’évènement “httpResponseStatus” diffusé par notre URLLoader, et de récupérer l’url finale accessible depuis la propriété “responseURL” du dit évènement :

public function init(e:FlexEvent):void {
	previewButton.addEventListener(MouseEvent.CLICK,onPreviewClick);
}
 
public function onPreviewClick(e:MouseEvent):void {
	if(urlToPreview.text=="") {
		Alert.show("URL invalide !");
	} else {
		var loader:URLLoader = new URLLoader();
		loader.addEventListener(HTTPStatusEvent.HTTP_RESPONSE_STATUS,onHTTPResponse);
		loader.load(new URLRequest(urlToPreview.text));
	}
}
 
public function onHTTPResponse(e:HTTPStatusEvent):void {
	var finalURL:String = e.responseURL;
	urlFinal.text = "URL finale = "+finalURL;
}

Et voila le résultat :

Ma méthode d’une classe Java doit faire une insertion dans cette table, et me retourner l’id (déclaré en clé primaire auto incrémentée), du coup voilà une manière de procéder :

public int doInsert(String query) {
		try {
			Connection handle = DriverManager.getConnection("jdbc:mysql://localhost/toshen?user=root");
			Statement stmt = handle.createStatement();
			stmt.executeUpdate(query,Statement.RETURN_GENERATED_KEYS);
			ResultSet keys = stmt.getGeneratedKeys();
			if(keys.next()) {
				int id = keys.getInt(1);
				System.out.println("ID inseré = "+id);
				return id;
			}
		} catch(SQLException e) {
			System.out.println("Something went wrong : "+e.getMessage());
		}
		return 0;
	}

J’utilise cette méthode ainsi :

// ...
doInsert("INSERT INTO characters(charact_name,gender,alignment) VALUES('Palleas','m','Loyal')");
// ...

Il ne vous manquera que les imports qui vont bien (sachant que Connection, Statement et ResultSet viennent du package java.sql), tout devrait fonctionner. Le executeUpdate prend en deuxième paramètre un flag. Il est obligatoire et permet de demander explicitement à Java de retourner les clés générées en retour. Sans ce flag, utiliser la méthode getGeneratedKeys() lèvera une exception de type SQLException. Le test sur la méthode “next” du ResultSet est important, il décale en effet le pointeur sur le tuple suivant (donc ici le premier) et vérifie que celui-ci existe, sans ça vous n’aurez pas accès aux clés.

• Le lundi, un billet est déposé sur le site façon “c’est parti pour la playlist de cette semaine !”, vous invitant donc à déposer vos liens Spotify uniquement.
• Le jeudi soir, un billet est posté, avec le lien vers la playlist ainsi créée, prête à être écoutée le vendredi.

Ça se passe ici, enjoy !

Le livre est la version française du tutoriel Jobeet, traduite et adaptée par Hugo dont j’ai pu suivre l’évolution du taux de fatigue au fur et à mesure que la traduction avançait. J’ai pour ma part assuré la relecture technique mais également le travail d’indexation du contenu (même que dans les remerciements, ils disent que j’ai fourni un travail remarquable, et ouais!).

C’est un peu drôle de me retrouver à faire ça, quand on sait que l’année dernière j’étais encore anti-framework PHP. Cette année d’alternance dans une boite avec 5 développeurs m’aura au moins enseigné les difficultés liées au développement en équipe, et ainsi révélé les avantages d’un framework.

Du coup courrez acheter le livre, il vaut vraiment le coup (on retiendra mon objectivité sur ce coup). Petit bémol pour la couverture et l’illustration absolument improbable que l’on retrouve systématiquement sur la collection des cahiers du programmeur, au moins on a évité les palmes du livre sur le Zend Framework ou le bébé de l’enfer sur le livre Java EE…

Merci à Eyrolles (et plus particulièrement à Muriel (Shan Sei Fan)), à Fabien (Potencier) et à Hugo (Hamon). L’expérience était vraiment enrichissante!

Un exemple typique étant un peu tout ça :

<s:Button label="Click Me !" click="handleClick(event)" />

<s:Application creationComplete="handleCreationComplete(event)" />

Pour moi la seule manière élégante de gérer les évènements reste le bon vieux addEventListener. Aussi, on pourra trouver des choses comme ça pour “limiter la casse” :

<s:Application 	xmlns:s="library://ns.adobe.com/flex/spark" 
			xmlns:fx="http://ns.adobe.com/mxml/2009"
			creationComplete="init(event)">
	<fx:Script>
	protected var app:MyUberApplication;
	public function init(e:FlexEvent):void {
		app = new MyUberApplication(this);
	}
	</fx:Script>
</s:Application>

De cette manière, on peut gérer les évènements proprement dans notre classe “MyUberApplication”, et limiter l’ajout d’Actionscript dans le MXML. Seulement voilà, pour moi cette manière de faire n’est pas complètement satisfaisante. L’ajout de code Actionscript dans le MXML me rappelle le vieil HTML 4.0 entrecoupé de javascript (exagération volontaire).

Je ne vais pas donner dans la critique gratuite sans proposer une solution, ceux qui suivent ce blog depuis longtemps savent que c’est un peu le genre de chose qui m’énerve. Voici donc la solution : le “code-behind” !. J’ai découvert ça récemment, et depuis je ne développe plus que comme ça!

Désormais, développer un composant se compose de plusieurs classes :

• Une classe Actionscript héritant d’un composant graphique (ex: Panel)
• Un composant MXML héritant de cette classe Actionscript
• Une classe Actionscript servant de “Value-Object”
• Une classe Actionscript héritant de la classe Event

Pour illustrer ce principe de fonctionnement, voici un composant permettant l’ajout d’un contact à un carnet d’adresse.

Développement de la première classe Actionscript :

package com.palleas.contact.components {
	import mx.containers.Panel;
	import mx.controls.Button;
	import mx.controls.TextInput;
	import mx.events.FlexEvent;
 
	public class AddContactBoxClass extends Panel {
		protected var _contactNameField:TextInput;
		protected var _contactEmailField:TextInput;
		protected var _addContactButton:Button;
 
		public function AddContactBoxClass() {
			super();
			addEventListener(FlexEvent.CREATION_COMPLETE,creationCompleteHandle);
		}
 
		protected function creationCompleteHandle(e:FlexEvent):void {
			removeEventListener(FlexEvent.CREATION_COMPLETE,creationCompleteHandle);
		}
 
		public function set nameField(field:TextInput):void {
			_contactNameField = field;	
		}
 
		public function get nameField():TextInput {
			return _contactNameField;
		}
 
		public function set emailField(field:TextInput):void {
			_contactEmailField = field;
		}
 
		public function get emailField():TextInput {
			return _contactEmailField;	
		}
 
		public function get addButton():Button {
			return _addContactButton;
		}
 
		public function set addButton(button:Button):void {
			_addContactButton = button;
		}
	}
}

Et voici le composant MXML qui en hérite :

<?xml version="1.0" encoding="utf-8"?>
<components:AddContactBoxClass 	xmlns:components="com.palleas.contact.components.*" 
						xmlns:mx="http://www.adobe.com/2006/mxml" 
						layout="vertical"
						title="Ajouter un contact">
	<mx:Label text="Nom" />
	<mx:TextInput id="nameField" />
	<mx:Label text="Email" />
	<mx:TextInput id="emailField" />
	<mx:Button id="addButton" label="Ajouter" />
</components:AddContactBoxClass>

Voici le “value-object” qui sera utiliser pour faire transiter les données :

package com.palleas.contact.vo {
	public class Contact {
		protected var _name:String;
		protected var _email:String;
 
		public function set name(n:String):void {
			_name = n;
		}
 
		public function get name():String {
			return _name;
		}
 
		public function set email(e:String):void {
			_email = e;
		}
 
		public function get email():String {
			return _email;
		}
	}
}

Et enfin, voici l’évènement qui sera diffusé lorsque la personne voudra ajouter un contact :

package com.palleas.contact.events {
	import com.palleas.contact.vo.Contact;
 
	import flash.events.Event;
 
	public class ContactEvent extends Event {
		static public const CONTACT_ADDED:String = "ContactAdded";
		protected var _contact:Contact;
 
		public function ContactEvent(type:String, contactVO:Contact=null,bubbles:Boolean=false, cancelable:Boolean=false) {
			super(type, bubbles, cancelable);
			if(null!=contactVO) {
				this.contact = contactVO;
			}
		}
 
		public function set contact(c:Contact):void {
			_contact = c;
		}
 
		public function get contact():Contact {
			return _contact;
		}
	}
}

Maintenant qu’on a tous les acteurs, on va pouvoir implémenter plus facilement l’aspect fonctionnel de notre composant, c’est à dire que l’on va “faire quelque chose” lorsque la personne voudra ajouter son contact. Pour ce faire, commençons par modifier la méthode creationCompleteHandle de la classe AddContactBoxClass, pour réagir au clique sur le bouton :

package com.palleas.contact.components {
	import com.palleas.contact.events.ContactEvent;
	import com.palleas.contact.vo.Contact;
 
	import flash.events.MouseEvent;
 
	import mx.containers.Panel;
	import mx.controls.Button;
	import mx.controls.TextInput;
	import mx.events.FlexEvent;
 
	public class AddContactBoxClass extends Panel {
		// ...
		protected function creationCompleteHandle(e:FlexEvent):void {
			removeEventListener(FlexEvent.CREATION_COMPLETE,creationCompleteHandle);
			addButton.addEventListener(MouseEvent.CLICK,buttonClickHandle);
		}
 
		protected function buttonClickHandle(e:MouseEvent):void {
			var createdContact:Contact = new Contact();
			createdContact.name = nameField.text;
			createdContact.email = emailField.text;
			var addContactEvent:ContactEvent = new ContactEvent(ContactEvent.CONTACT_ADDED,createdContact);
			dispatchEvent(addContactEvent);
		}
		// ..
	}
}

On a ajouté un écouteur sur le bouton. Lors du clique, on recréé un “value-object” Contact contenant les valeurs spécifiées par l’utilisateur (le nom, et l’adresse E-mail). On créé ensuite un évènement qui diffusera ce “value-object”.

Enfin, pour utiliser proprement ce composant dans mon application Flex, je vais implémenter de nouveau ce principe du “code-behind” pour mon application. Je créé donc ma classe MainApplicationClass, qui hérite du composant Flex “Application” :

package com.palleas.contact.components {
	import com.palleas.contact.events.ContactEvent;
	import com.palleas.contact.vo.Contact;
 
	import mx.controls.Alert;
	import mx.core.Application;
	import mx.events.FlexEvent;
 
	public class MainApplicationClass extends Application {
		protected var _addContactBox:AddContactBox;
 
		public function MainApplicationClass() {
			super();
			addEventListener(FlexEvent.CREATION_COMPLETE,creationCompleteHandle);
		}
 
		protected function creationCompleteHandle(e:FlexEvent):void {
			removeEventListener(FlexEvent.CREATION_COMPLETE,creationCompleteHandle);
			addContactBox.addEventListener(ContactEvent.CONTACT_ADDED,onContactAdded);
		}
 
		protected function onContactAdded(e:ContactEvent):void {
			var contactAdded:Contact = e.contact;
			Alert.show("Un contact a été ajouté :\n"+contactAdded.name+" // "+contactAdded.email);
		}
 
		public function set addContactBox(box:AddContactBox):void {
			_addContactBox = box;
		}
 
		public function get addContactBox():AddContactBox {
			return _addContactBox;
		}
	}
}

Ce qui donne pour mon fichier MXML principal :

<?xml version="1.0" encoding="utf-8"?>
<components:MainApplicationClass xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute" xmlns:components="com.palleas.contact.components.*">
	<components:AddContactBox id="addContactBox" width="100%" />
</components:MainApplicationClass>

Ainsi, lorsque je clique sur mon bouton, un évènement est diffusé. Cet évènement est récupéré par mon application principale, qui ainsi affiche une alerte affichant les informations du contact ajouté :

En conclusion, c’est sans doute pour moi la manière la plus propre de procéder pour développer avec Flex. De cette manière, tout est bien décomposé, et c’est ainsi que l’on pourra facilement implémenter un vrai MVC beau et propre. Comme je le disais je ne code plus que comme ça, mais pas depuis vraiment longtemps, si vous avez des remarques ou des questions, les commentaires sont la pour ça!

(Petit bémol cependant, je n’ai volontairement pas parlé de vérification ou de stockage des valeurs saisies, ce n’était pas le but du tutoriel, et il était suffisamment long comme cela.)

<?xml version="1.0" encoding="utf-8"?>
<s:Application 	xmlns:s="library://ns.adobe.com/flex/spark" 
				xmlns:fx="http://ns.adobe.com/mxml/2009"
				xmlns:com="com.palleas.*">
	<!-- Declaration du Vector -->
	<fx:Declarations>
		<fx:Vector id="myVectorList" type="com.palleas.Touriste">
			<com:Touriste lastname="Brian" />
			<com:Touriste lastname="Stewart" />
			<com:Touriste lastname="Martin" />
		</fx:Vector>
	</fx:Declarations>
	<!-- Affichage de la taille de ce vector : le nombre d'éléments contenus -->
	<s:TextInput text="{myVectorList.length}"/>
</s:Application>

Rien de très compliqué ici, j’ai limité le Vector à ne contenir que des éléments de type “Touriste” (cette classe venant du tutoriel précédent). Le fonctionnement basique ne change pas, si vous essayez de mettre un élément de type autre celui spécifié dans l’attribut type (genre un String), vous aurez une erreur à la compilation. Personnelement, je n’utilise que très peu (sinon pas) ne composant non-graphiques dans mon MXML, mais bon c’est à vous de voir!

Avec Flex 3, l’implémentation du DataBinding donnait quelque chose comme ça (l’étiquette Bindable permettant de dire explicitement au compilateur “d’écouter” les modifications effectuées sur cette variable) :

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="vertical">
	<mx:Script>
		<![CDATA[
		[Bindable]
		protected var myVar:String;
		]]>
	</mx:Script>
	<mx:TextInput text="{myVar}" />
</mx:Application>

Ce qu’il manquait finalement, c’était que cette modification puisse se faire dans les deux sens, c’est à dire que lors de la modification de la variable, le contenu du champs de texte se mette à jour, mais que lors de la modification du contenu du champs de texte, la variable se mette à jour également. Notez bien l’utilisation du passé car avec Flex 4, c’est possible !

Two-Way Binding : MXML style

La première manière de déclarer ce data-binding étant d’utiliser le tag “Binding” de MXML :

<fx:Binding source="textField1.text" destination="textField2.text" twoWay="true" />
<!-- ... -->
<s:TextInput id="textField1" />
<s:TextInput id="textField2" />
<!-- ... -->

De cette manière, le contenu de mes deux champs de texte est systématiquement la même car leurs propriétés “text” sont liées. Notez l’utilisation de l’attribut twoWay=”true”, c’est la seule véritable différence avec Flex 3. Si cet attribut est omis, la liaison ne se fera que dans un sens (la valeur de la propriété déclarée dans “destination” prenant la valeur de celle déclarée dans “source”).

Two-way Binding : inline style

Il existe une autre manière de faire, directement dans le contenu des balises MXML, via une syntaxe très légèrement différente de ce qu’on faisait avec Flex 3, “@{propriété bindable}”. Pour reprendre l’exemple précédent, cela donnerait quelque chose comme ça :

<!-- ... -->
<s:TextInput id="textField1" />
<s:TextInput id="textField2" text="@{textField1.text}" />
<!-- ... -->

Ce fonctionnement reste le même dans le cas de propriété bindable déclarée en Actionscript :

<!--  ... -->
<!-- Propriété bindable -->
<fx:Script>
	<![CDATA[
		[Bindable]
		protected var myVar:String;
	]]>
</fx:Script>
<!-- Champ de texte mettant à jour cette propriété -->
<s:TextInput id="textField2" text="@{myVar}" />
<!-- One-way DataBinding, pour montrer que la valeur de la
propriété "myVar" évolue bien -->
<s:TextInput text="{myVar}" />
<!--  ... -->

Voila pour la présentation de cette nouvelle fonctionnalité, qui devrait simplifier vos développement. Personnellement c’est quelque chose qui m’avait vraiment manqué, c’est donc plutôt une bonne nouvelle de le voir implémenté dans cette nouvelle version de Flex, sans que ça bouleverse trop les habitudes de développement (un “@” à rajouter dans le html, ou un attribut “twoWays” à préciser, on devrait pouvoir s’en sortir). A bientôt pour de nouvelles aventures et désolé, je crois que j’ai un peu tripé sur les titres en anglais.

currentState = null, currentState = “”

Désormais, dans le cas ou un composant aurait des spécification de changement d’états, l’état par défaut du composant serait le premier de la liste. Il vous faut donc déclarer l’état “par défaut”.

<?xml version="1.0" encoding="utf-8"?>
<s:Application 	xmlns:s="library://ns.adobe.com/flex/spark"
				xmlns:fx="http://ns.adobe.com/mxml/2009">
	<!-- States -->
	<s:states>
		<s:State name="default" />
		<s:State name="state1" />
		<s:State name="state2" />
	</s:states>
	<s:Button label="Hi, I'm a button !" />
</s:Application>

De cette manière, pour revenir à l’état par défaut, il faudra revenir à l’état ici nommé “default” (j’aurais pu le nommer comme je le veux, mais “default” semblait être le choix le plus pertinent.).

addChild, removeChild

L’ajout et la suppression de composant a également été repensée, pour la rendre bien plus pratique à utiliser. Fini les target=”{myComponent}” position=”after”, il faudra désormais passer par les attributs excludeFrom et IncludeIn. Ces attributs prenant comme valeur la liste des états auxquels insérer ou supprimer ledit composant. Si ces attribut sont omis, le composant sera affiché dans l’état par défaut.

<?xml version="1.0" encoding="utf-8"?>
<s:Application 	xmlns:s="library://ns.adobe.com/flex/spark"
				xmlns:fx="http://ns.adobe.com/mxml/2009">
	<s:layout>
		<s:VerticalLayout />
	</s:layout>
	<!-- States -->
	<s:states>
		<s:State name="default" />
		<s:State name="state1" />
		<s:State name="state2" />
	</s:states>
 
	<!-- Button : visible everywhere -->
	<s:Button label="Button #1" />
	<!-- Button : only visible in state1 -->
	<s:Button label="Button #2" includeIn="state1"/>
	<!-- Button : visible everywhere but in state2 -->
	<s:Button label="Button #3" excludeFrom="state2" />
 
	<!-- switch states -->
	<s:Button label="default State" click="currentState='default'" />
	<s:Button label="State 1" click="currentState='state1'" />
	<s:Button label="State 2" click="currentState='state2'" />
</s:Application>

setProperty, setStyle, setEventHandler

La modification de propriété, de style, d’écouteur ne peut plus se faire via les méthodes respectives setProperty, setStyle et setEventHandler. A la place, une nouvelle syntaxe a été mise en place, on utilisera donc toujours attribut=”value” pour spécifier la valeur d’un attribut, et on utilisera attribut.XXX=”other value” pour spécifier la valeur de l’attribut lorsque l’on se trouve sur le state XXX.

<?xml version="1.0" encoding="utf-8"?>
<s:Application 	xmlns:s="library://ns.adobe.com/flex/spark"
			xmlns:fx="http://ns.adobe.com/mxml/2009">
	<s:layout>
		<s:VerticalLayout />
	</s:layout>
	<!-- States -->
	<s:states>
		<s:State name="default" />
		<s:State name="state1" />
		<s:State name="state2" />
	</s:states>
 
	<s:Button 	label="Default label" label.state1="Label State 1" label.state2="Label State 3" />
 
	<!-- switch states -->
	<s:Button label="default State" click="currentState='default'" />
	<s:Button label="State 1" click="currentState='state1'" />
	<s:Button label="State 2" click="currentState='state2'" />
</s:Application>

Cela implique qu’il est désormais impératif de déclarer des noms de state “xml-attribute-compliant”, c’est à dire éviter les “.”, les “:”, etc.

Je conclurai en disant que pour ma part, ce changement est des plus pertinent. Il devient ainsi possible retrouver très facilement tous les états d’un composant au même endroit.