[Spark] Changement de skin au runtime et comportements étranges

[Jim_Nastiq]

Salut,

J'ai un souci plutôt étrange avec le changement de skin au runtime. Lorsque je change switch de skin avec la méthode loadStyleDeclarations du StyleManager, je perds tous mes listeners sur mes composants et l'affichage de mes listes...

en mode debug quand je check mes dataprovider sont bien affectés avec les bonnes valeurs, mes boutons ont bien des listeners , mais plus rien ne se passe...
au complete du siwtch de skin j'ai tenté validateNow, invalidateProperties, invalidateDisplayList mais rien n'y fait, mes composants semblent "bloqués" dans un état inutilisable... J'ai même tenté d'écouter un autre event sur l'un des boutons et il n'est jamais levé.

Vous trouverez ci-joint , un projet illustrant le probleme. Il suffit de sélectionner dans la combobox "Evovled" pour switcher de skin et s'appercevoir que la combo se vide et que les boutons deviennent inutile.

[Madfrix]

Bonjour,

effectivement cela ne marche pas...

A mon avis cela est du au fait qu'un changement de skin d'après moi supprime tous tes skin parts déjà présents pour les recréer (dans ta situation tu as les mêmes parties entre tes 2 skins mais cela n'est pas forcément le cas).

Pour une raison obscure, tes events sont encore bien présent ensuite mais ne sont pas fonctionnels car ils doivent se trouver dans un état instables (composant supprimé sans suppression préalable des events puis recréation de ces composants) donc à mon avis tes events sont liés à tes composants juste par le nom mais c'est tout (explication vaseuse mais j'ai rien de mieux).

Pour en revenir à ton problème, une solution serait peut être de créer tes events via un creationComplete sur ton skin et pas avant.

Pour ma part je procéderais différemment. J'ai l'habitude de considérer qu'un changement de skin reflète un changement de comportement du composant ce qui dans ton cas de figure n'est pas le cas (tu souhaites garder les mêmes events sur les mêmes composants) donc ce que tu veux faire serait plutôt un changement d'état de composant (qui impacte plus la partie visuelle au sens propre). En résumé, si changement de comportement->skin, si changement visuel->state. Mais ce n'est que mon avis

En testant ton code dans ton switch, si tu mets :

Code :

1
2
 
skin.currentState = "disabled";

pour tester, tu verras que ton composant reste fonctionnel, reste plus qu'à modifier pour créer des états perso et modifier l'apparence dans tes fichiers de skins.

En espérant avoir aidé

[Jim_Nastiq]

Merci Madfrix poru ton retour. Je ne suis pas vraiment d'accord avec toi sur le fond, pour moi un skin est purement "visuel" et non comportemental. Donc je ne comprend pas le comportement qu'a mon application jointe à mon précédent message.

dans ta situation tu as les mêmes parties entre tes 2 skins mais cela n'est pas forcément le cas

c'est justement l'utilité d'un skin ... c'est pouvoir habiller des éléments et pas avoir a te retaper le "fonctionnel" a chaque fois

bref, y'a un truc qui m'échappe vraiment la ...

[Madfrix]

Envoyé par Jim_Nastiq

c'est justement l'utilité d'un skin ... c'est pouvoir habiller des éléments et pas avoir a te retaper le "fonctionnel" a chaque fois

Oui je sais bien mais justement imagine le cas ou tu définis ton btnOne à required = false. Donc rien n'empeche ton CustomViewEvolvedSkin à ne pas l'implémenter dans son skin. Or, dans le composant tu mets un écouteur sur btnOne. Au changement de skin (basic->evolved) tu auras une erreur.

Sur le fond, je suis d'accord aussi avec toi, c'est possible de faire ce que tu fais par contre à mon avis, tout deviens instable car tes ecouteurs ne sont plus liés aux bon objets du moins c'est ce que je pense. C'est pourquoi je conseillais de créer les events une fois le skin en place et de les retirer à l'appel d'un nouveau skin.

Sinon un article intéressant ici qui peut éventuellement être utile

[Jim_Nastiq]

Envoyé par Madfrix

C'est pourquoi je conseillais de créer les events une fois le skin en place et de les retirer à l'appel d'un nouveau skin.

Si tu as raison, j'avoue que je suis hyper sceptique sur la réelle utilité des skins sur des applis conséquente


PS: j'ai fait un test en faisant un remove des listeners lors du changement de skin, et rajout des listeners une fois le skin chargé = idem, rien ne fonctionne!

[Madfrix]

Envoyé par Jim_Nastiq

Si tu as raison, j'avoue que je suis hyper sceptique sur la réelle utilité des skins sur des applis conséquente

Tu appliques ton skin une fois pour toute, ensuite tu joues avec tes states

Dans ton cas de figure, c'est juste une redisposition de tes skin parts donc pas besoin de skinner de nouveau.

Ca reste encore mon point de vue

[Jim_Nastiq]

Euh non justement un skin tu ne l'appliques pas une fois pour toute !

Si je veux refiler le skinning de mon appli à un graphiste je lui refile une librairie de mes composants et il bosse sous Flasb Builder et/ou Flash Catalyst après avoir exporter ses créa en FXG par exemple. Il me sort un swf (CSS compilé) et avec mes SkinPart à TRUE, le compilo lui annonce direct si il a oublié des éléments dans la skin. Si il doit me coder des states et cie ca commence a etre tendu pour lui et pour moi! le principe des skin c'est permettre a des graphiste de te fournir un travail immédiatement utilisable sans avoir besoin d'une adaptation d'un coté ou de l'autre (dev / graphisme).

EDIT: pour moi un skin c'est ca : utilise la combo "Styles". Bon c'est du Flex 3 donc uniquement du CSS pas de vrai skin avec les Sparks component mais le principe est la!

[Madfrix]

Envoyé par Jim_Nastiq

Euh non justement un skin tu ne l'appliques pas une fois pour toute !

Désolé je m'exprime mal ^^

Je précise : un skin s'utilise une fois pour toute ET pour un comportement donné du moins c'est comme cela que je vois les choses.

En pj j'ai refais ton projet comme je le créerais moi même.

[Jim_Nastiq]

Merci MadFrix pour ton aide, mais dans ton cas, comment avoir un état disable (grisé) sur les 2 skins différents??
Admettons que mon skin Evolved soit pour un utilisateur avec des droits Admin et le skin de base pour un utilisateur de base. je vais vouloir grisé (et donc mettre enable à false => state disable) certains composant pour mon admin par exemple, mais avec ta solution ceci n'est pas possible! soit je suis en mode Evolved soit en mode disable mais pas possible d'avoir les deux.

ce que je souhaite c'est vraiment un skin qui possède des états qui sont propres à mon application et pas propre a un skin !
En gros les states c'est "métier", c'est "comment se comporte mon application dans tel cas", alors qu'un skin "c'est comment se présente mon application dans tel cas"

[Madfrix]

Envoyé par Jim_Nastiq

Admettons que mon skin Evolved soit pour un utilisateur avec des droits Admin et le skin de base pour un utilisateur de base. je vais vouloir grisé (et donc mettre enable à false => state disable) certains composant pour mon admin par exemple, mais avec ta solution ceci n'est pas possible! soit je suis en mode Evolved soit en mode disable mais pas possible d'avoir les deux.

Il te suffit de rajouter un state "admin" et de le mettre dans le même group de states (admettons "users") que "base". Les statesGroup sont typiquement crées pour gérer ces cas de figure ou seuls différent entre 2 states certaines différences

[Jim_Nastiq]

Salut Madfrix,

encore une fois merci pour ton aide. Mais il va falloir encore m'expliquer comment tu peux faire avec ta méthode ce que je cherche a faire

Disons que ma CustomView à 3 états (states) : vueA , vueB, vueC. Sur cette customView je veux pouvoir changer de skin , donc si je te suis je dois rajouter autant d'état que de skin souhaité.

J'aurais donc les states suivant (normal et disabled on en fait abstraction pour l'exemple) :

Code :

1
2
3
4
5
6
7
8
 
<s:states>		
		<s:State name="vueA" />
		<s:State name="vueB" />
		<s:State name="vueC" />
		<s:State name="skinA" />
		<s:State name="skinB"  />
</s:states>

Tu m'as indiqué d'utiliser les stateGroups, mais je ne vois pas comment ils vont m'aider :s.
Comment puis je changer à ma convenance d'états vueA, vueB et vueC tout en restant sur le skinA, puis a un autre moment pouvoir passer de ma vueA a ma vueB voir ma vueC en étant sur mon skinB ?? Puis encore a un autre moment etre sur ma vueA en skinA et passer sur skinB tout en restant sur ma vueA ??

y'a un truc qui m'échappe vraiment

[Madfrix]

Salut,

non en fait l'idée d'après moi serait de mettre en place un système d'authentification dans le composant (component state) et de définir l'apparence à part dans les états de skin (skin state). Libre à toi ou non de lier via une fonction (override de getCurrentSkinState) les skinStates et les states de ton composant.

En pj, j'ai fais un petit projet

EDIT: avec la pj c'est mieux...

[Jim_Nastiq]

Salut,

je reviens avec qq billes... alors déjà le problème que je décrit intervient lors du changement de la propriété de style skinClass.
Après debug il apparait que le changement de skinClass réinstancie tous les skinPart du SkinnableContainer, ce qui explique pourquoi nous perdons les listeners, dataprovider et cie, car addresse mémoire différente pour les skinPart. Cependant ca n'explique pas pourquoi la méthode hasEventListener renvoi true

Bref, j'ai un début de réponse qui ne me satisfait pas du tout

[Madfrix]

Bonjour,

Envoyé par Jim_Nastiq

Après debug il apparait que le changement de skinClass réinstancie tous les skinPart du SkinnableContainer, ce qui explique pourquoi nous perdons les listeners, dataprovider et cie, car addresse mémoire différente pour les skinPart

c'est ce que je disais plus haut, tes composant se trouvent dans un état instable car tu supprimes ton composant (composant skin qui comme tu le dis supprime tes parties de skin) sans au préalable supprimer les events puis tu recrées le skin donc forcément ca part en vrille.

Personnellement sans vouloir paraitre lourd (), je verrais plutôt l'instanciation d'un skin une bonne fois pour toute et après tu joues avec tes components states et tes skins states.

...non ?

[Jim_Nastiq]

Merci Madfrix,

mais ton explication ne tient pas, cf l'adresse mémoire qui change... comment peut on avoir une nouvelle adresse mémoire pour un bouton et garder une référence obscure à un listener sans garder le handler ...

et pour le "skin une bonne fois pour toute" => c'est naze !
Ca correspond pas du tout a ce que je souhaite! Considère que j'ai une application conséquente, que j'ai pour le moment un skin (avec tous pleins de skin mxml développé et un css rempli de mention à la propriété skinClass) mais qu'a l'avenir je n'exclu pas le fait de proposer d'autres skins à mes utilisateurs, et même la possibilité a certains designer/flexeur de se faire leur propre skin.
Ceci étant dit, tu comprends que je ne peux pas me passer de la propriété skinClass et que je dois garder du dynamisme dans mon appli et pas ajouter des states à gogo
la solution c'est skinClass, mais son comportement au runtime m'échappe encore...

[Madfrix]

Ba c'est comme tu veux mais ton traitement sera plus lourd libre à toi de continuer sur cette voie

J'ai regardé à nouveau ton problème sur un cas simple et je pense avoir réussi à trouver sinon la solution, du moins une piste.

Exemple :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
 
<?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/mx">
 
	<fx:Script>
 
		<![CDATA[
 
		import mx.collections.ArrayCollection;	
 
		import skins.DropSkin1;
		import skins.DropSkin2;
 
		[Bindable] protected var ac:ArrayCollection = new ArrayCollection([{label:"skin1", skin:"skins.DropSkin1"}, {label:"skin2", skin:"skins.DropSkin2"}]);
 
		protected function changeSkin(e:Event):void
		{
			// référence vers la classe de skin
			var ref:DropSkin2;
 
			var clazz:Class = getDefinitionByName(ddl.selectedItem.skin) as Class;
 
			ddl.setStyle("skinClass", clazz);
		}
 
		]]>
	</fx:Script>
 
	<s:layout>
		<s:VerticalLayout />
	</s:layout>
 
	<s:DropDownList id="ddl" dataProvider="{ac}" labelField="label" selectedIndex="0" skinClass="skins.DropSkin1" />
	<s:Button label="change skin" click="changeSkin(event)" />
 
 
</s:Application>

j'ai 2 skins pour ma DropDownList que je veux changer via un bouton. L'idée est donc de changer la classe du skin comme tu veux le faire. Or, si tu fais un getDefinitionByName("package.classe"); puis que tu l'appliques au style skinClass tu compileras mais tu auras une erreur d'exécution même si tu importes cette classe car, et c'est la que c'est subtil, le compileur vire les classes non utilisées par l'appli et il est trop con pour savoir que tu vas utiliser ta classe package.classe ensuite. La solution, consiste donc à créer une référence vers cette classe implicitement (cf: mon code)