Voici une petite astuce d’écriture pour éviter de devoir inverser les conditions lorsqu’on les place dans du code mxml. En effet, Flex ne supporte pas que l’on ait les opérateur && dans du code mxml.
Le code : <mx:Label text= »matsiya » visible= »{condition1 && condition2} » /> devrait fonctionner dans la logique, puisque <mx:Label text= »matsiya » visible= »{condition1 || condition2} » /> fonctionne très bien, mais ce n’est pas le cas.
On pourrait certainement chercher pourquoi derrière il refuse cette compilation car le code mxml n’étant autre que du code as3, la raison doit se trouver là dedans. Néanmoins, ce problème d’écriture résulte souvent dans une prise de tête.
Pour le contourner, il suffit alors d’écrire sous la forme suivante :
<mx:Label text= »matsiya » visible= »{(int(condition1)*int(condition2))==1} » />
Cela rend le code un peu moins lisible, mais est terriblement efficace.
Articles sur le même sujet :
Intéressant,
Reste que ça ne risque pas d’alourdir un le code et de rendre la maintenance complexe cette utilisation des balises ?
Dans un projet de production, est-ce que vous privilégiez l’utilisation du MXML ? de l’AS3 ? ou alors vous en mettez un peu dans les 2 ?
Je cherche des infos sur un structure propre d’application Flex parce que rapidement je trouve qu’on en met un peu partout, ce qui n’est pas simple par la suite à déboger ou faire évoluer
Bonjour,
Concernant l’utilisation plutot de mxml ou d’AS3, nous utilisons tout ce qui est handler d’événements (clicks, actions clavier, remoting, …) dans des fonctions AS3, généralement dans le même fichier mxml. Et tout ce qui est gestion d’affichage dans le mxml. Donc typiquement l’utilisation des conditions d’affichage de l’exemple au dessus est placé directement dans le code mxml.
Il suffit pour ne pas alourdir l’affichage de faire des retours à la ligne.
Nous ne sommes pas favorable à l’utilisation de classes as3 séparées, cela fait créer pleins de fichiers pour pas grand chose au final.
Par contre, nous utilisons beaucoup les composants, cela permet de bien découper le projet, et d’avoir une bonne part de réutilisabilité.
Enfin pour vraiment rendre propre son code, il suffit de regrouper les fonctions privées/publiques, de bien commenter, et de regrouper les fonctions qui ont un roles plus ou moins identiques.
le problème évoqué du && vient du fait que les caractères cherchent à être interprétés comme du HTML, donc la solution c’est de les mettre en HTML soit &&
Du coup :
devient :
Petit problème de parsing dans mon commentaire précédent…
La solution est de mettre le caractère HTML correspondant à & à la place soit : & suivi de amp; (&_amp; en enlevant l’underscore)
ou sinon remplacer tout simplement « && » par « && » de le bloque mxml cela marche très bien.
« & a m p ; & a m p ; » sans les espaces
visible= »{condition1 && condition2} »
zut
visible= »{condition1 & amp;& amp; condition2} »
sans les espaces
Bonjour,
Le MXML est un format XML a la sauce Macromedia.
Lors de la compilation, le fichier MXML sert de description pour la génération des classes AS.
L’opérateur ‘&&’ n’est pas toléré en MXML. En revanche ‘&&’ fonctionne très bien comme la majorité des langages de description XML.
Bonjour,
A priori il est plus simple d’utiliser la notation && au lieu de &&. Ce n’est pas tellement flex qui ne supporte pas cette notation mais comme les documents MXML sont avant tout des documents XML ils héritent des mêmes contraintes.
Même si ça peut sembler bizarre au premier abord, c’est plutôt logique (codage XML des caractères dans les attributs).
(j’espère que l’affichage du message ne sera pas trop explosé à cause des caractères spéciaux
)
c’est ce que je craignais : dans le message précédent il fallait lire & amp ; & amp ; (supprimez les espaces inutiles)