loul il semble qu'il y ait quelques soucis de compréhension
Bon reprenons depuis le début.
1) soit un composant AS, TitleWindowDroit, héritant de TitleWindow
2) soit un attribut droitConsultation, rajouté au composant TitleWindowDroit et initialisé avec la valeur "O"
pour l'instant on a un truc du style :
3) ce composant perso est destiné à être affiche en tant que Popup
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5 public class TitleWindowDroit extends TitleWindow{ public var droitCreation:String="O" }
4) Sur le principe, l'affichage de cette fenêtre se fera à partir d'un "lien", mais en aucun cas je ne veux utiliser de linkButton. (En fait je passe par un Tree mais cela n'a pas d'importance, ne compliquons pas les choses).
5) Le principe est le suivant : je dois savoir AVANT l'affichage de la fenêtre si l'utilisateur courant a effectivement le droit de consulter ou non cette fenêtre de manière à lui proposer le moyen d'y accèder (via une entrée dans le Tree). L'utilisateur ne peut donc accèder à la fenêtre que si celle-ci a son attribut droitConsultation positionné à "O".
6) soit une situation qui fait que maintenant plus personne n'a le droit de voir cette fenêtre. Je positionne donc droitConsultation à "N" dans la balise TitleWindowDroit qui définie la racine de ma fenêtre décrite dans le fichier MXML "MaFenetrePerso" :
7) Si tout le monde ne s'est pas endormi arrivé ici alors on continue
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4 <customcompAS:TitleWindowDroit droitConsultation="N" > [le contenu de ma fenetre] </customcompAS:TitleWindowDroit>
Pour connaitre la valeur effective de mon attribut droitConsultation AVANT l'affichage (ou pas) de ma fenêtre, je ne fais que (naïvement?) l'instantier en AS :
8) Problème : la valeur que je récupère dans le test ci-dessus est celle par défaut définie dans la classe AS définissant ma TitleWindowDroit et non pas celle que j'ai affecté dans le MXML ! Je reçois donc "O" au lieu de "N".
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8 var fenetre:MaFenetrePerso = new MaFenetrePerso(); if(fenetre.droitConsultation == "O"){ //alors je donne à l'utilisateur la possibilité à l'utilisateur d'accèder à cette fenetre via une entrée dans mon Tree (d'où l'analogie avec un lien) } else{ //Je n'affiche pas l'entrée dans mon Tree }
Voilà voilà ma seule question est : comment résoudre ce problème apparent d'affectation ? Sachant que en faisant des essais, je me suis aperçu que l'affectation ne se faisait que si la fenêtre était affichée. J'ai donc l'impression, comme le disais un participant précédemment, que l'objet n'est pas totalement construit avec toutes les valeurs qui vont bien. Or ce n'est pas ce que je veux...
Désolé si j'ai pu être vague (et si je le suis encore ) et j'en profite pour remercier tous les participants qui prennent de leur temps pour me répondre.
Bon en fait je te proposerait une stratégie pas forcément propre mais qui te permettera de contourner ton problème et donc d'avancer :
- Etends ton TitleWindow customisé avec droitConsultation='N' (ou bien fait une classe pseudo abstraite [car ça n'existe pas vraiment en as] et deux implémentation, à toi de voir...)
- fait ton test AVANT d'appeler le popupmanager et construit la bonne implémentation de ta title window (qui sera donc initialisée avec le bon droitConsulation à la construction...
C'est pas terrible, mais je pense que ça aura au moins le mérite de marcher...
En effet, ça devrait marcher mais c'est un peu goret
Je ne suis pas sur d'avoir tout suivis mais en gros ta fenetre est "cree" quoi qu'il arrive avec son contenu (vu que tu regarde les valeurs qui sont dedans) et les droits des utilisateurs determine si ils peuvent l'ouvrir ou pas.
Cela paraît bizarre comme implémentation cela veut dire qu'un utilisateur non autorisé à la voir récupère les données qu'il ne doit pas voir sur ton serveur et charge son flex de cree un composant qui ne lui sert à rien. Cela ressemble à une pertes de ressources et un gros trou de sécurité ton truc...
Mais je suis pas sur d'avoir vraiment compris ce que tu cherche à faire
Je suis d'accord !!!!
Je pense qu'il faudrait que tu revois ta conception. Créé un composant pour rien n'est pas très bon. Ce que je voulais te faire comprendre avec le LinkButton c'est que tu ne devrais créer la fenêtre que au moment où tu veux l'afficher et pas avant. Si tu veux garder des informations met le dans un objet et pas dans un composant (Modèle Vue Contrôleur). J'ai l'impression que tu voudrais manipuler ton TitleWindow comme un objet de ton modèle or il faut faire la part des choses.
Tu vois ce que je veux dire
Pardonnez mon intervention, mais la question n'est pas de savoir si la logique de l'application est bonne ou mauvaise.
La question est de comprendre pourquoi la propriété d'un objet MXML instancié n'est pas immédiatement accessible.
Quand on a une incompréhension technique il est préférable de trouver une explication plutôt que de contourner le problème en changeant de logique...
jylaxx, la solution passe parfois par le contournement d'un problème, et si en plus ce petit détour améliore un autre aspect (ergonomie, logique architectural,...) c'est tant mieux
Dans l'entraide il y a une part de conseil et pas seulement de réponse ponctuel a un probleme précis
Pour le problème il faudrait effectuer des tests avec la méthode invalidateProperties et ses cousines peut être
Jim je comprends mais je ne suis pas d'accord...
Pour écrire un bon programme il faut d'abord bien maîtriser les outils qu'on utilise.
Passer trop vite sur une interrogation peut entraîner une mauvaise compréhension pouvant impacter le bon usage de l'outil. Au contraire prendre le temps de comprendre permet d'améliorer ses connaissances et ses compétences.
Je veux bien que l'on propose de meilleures solutions mais uniquement après avoir répondu à la question initiale.
Le but de ces échanges c'est de faire progresser tout le monde, aussi bien celui qui interroge que celui qui répond et que celui qui lit.
on est d'accord, hors sujet clos!
Fichman tiens nous au courant des tests avec la méthode invalidateProperties (tu trouveras des infos dans la doc si besoin)
Fichman pour répondre plus directement à ton problème:
J'ai fait des tests en utilisant ton modèle de classe, c'est à dire :
Une classe AS :
Une classe MaFenetrePerso MXML :
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16 package fr.xxx.flex.test { import mx.containers.TitleWindow; public class TitleWindowDroit extends TitleWindow { public var droitCreation:String = "O" ; public var droitConsultation:String = "O" ; public function TitleWindowDroit() { super(); } } }
Puis en faisant :
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8 <?xml version="1.0" encoding="utf-8"?> <TitleWindowDroit xmlns="fr.xxx.flex.test.*" xmlns:mx="http://www.adobe.com/2006/mxml" width="400" height="300" droitCreation="N"> </TitleWindowDroit>
J'obtiens bien
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3 var m : MaFenetrePerso = new MaFenetrePerso() ; trace( m.droitCreation ) ; trace( m.droitConsultation ) ;
N
O
Dans tes exemples tu utilises un coup droitCreation, un coup droitConsultation. Est-ce que tu t'es pas mélangé les pinceaux à ce niveau ??
Je suis d'accord sur le principe de ta remarque, le problème c'est qu'on peut pas faire autrement, car chaque composant se gère tout seul comme un grand au niveau des droits d'accès.
Alors si t'as une solution qui me permet de récupérer la valeur d'un attribut sans instancier l'objet, je suis preneur.
Pour çà il faudrait un peu plus d'information sur ton application
Les seuls attributs d'un objet accessibles sans instanciation sont les attributs static.
Dans ce cas bien entendu l'attribut est le même pour toutes les instances.
Comment peut-on envisager d'accéder à des variables qui n'existent pas !!!!!!
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaahhhhhhhhhhhhhhhhh !!!!!!!
J'ai trouvé.
Je pense que je n'ai pas été assez exact dans ma description.
En effet, je ne mets pas directement droitConsultation="N" mais droitConsultation="{Const.NON}"
Le résultat de jylaxx m'avait intrigué, j'ai donc fais quelques tests supplémentaires. Résultat : quand on met directement droitConsultation="N", alors OK j'ai bien mon affectation, par contre si je mets droitConsultation="{Const.NON}" alors là ça ne marche plus.
J'ai donc un peu du mal à comprendre comment Flex construit son objet en AS. Apparemment le binding n'est pas activé. J'ai peut-être loupé quelque chose ?
Tu nous dit pas d'où sors ton Const.NON !!!
Je vais supposer qu'il s'agit d'une unité Const dans lequel est définie une constante static du genre public static const NON : String="N";
Le bind droitCreation="{Const.NON}" ne conduit pas à la modification de la propriété car le binding utilise des événements. Hors tant que ton objet n'est pas inséré dans une DisplayList il ne reçoit aucun événement donc droitCreation reste à la valeur "O".
Il en est de même pour les événements preinitialize, initialize et creationComplete que l'on serait tenté d'utiliser pour initialiser des propriétés.
Le plus simple si tu veux conserver cette logique serait d'utiliser une classe AS à la place de ta classe MXML. Tu auras beaucoup plus de souplesse de programmation.
Pense aussi à remettre en cause ton architecture qui me parait (comme à d'autres ici) un peu bizarre...
En effet c'est une constante.
OK merci de l'explication très instructive.
Quant à l'architecture "bizarre" c'est une volonté du chef de projet d'intégrer dans les composants même la logique de droit et des obligations de saisie.
Ceci pour la simple raison de ne plus avoir à coder à chaque fois à la main le comportement des composants suivant les droits de l'utilisateur.
Ainsi le développeur (c'est à dire moi ) n'a plus qu'à utiliser les composants perso tels quels et ça marche "tout seul".
Evidemment, derrière c'est un peu (beaucoup) complexe...
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager