=head1 NOM Tk::ConfigSpecs - Définir le comportement de 'configure' pour les widgets composites. =head1 SYNOPSIS sub Populate { my ($composite,$args) = @_; ... $composite->ConfigSpecs('-attribut' => [ where,dbName,dbClass,defaut ]); $composite->ConfigSpecs('-alias' => '-autreattribut'); $composite->ConfigSpecs('DEFAULT' => [ where ]); $composite->ConfigSpecs($subwidget->ConfigSpecs); ... } $composite->configure(-attribut => valeur); =head1 DESCRIPTION Il s'agit de faire en sorte que la méthode configure d'un widget composite ressemble autant que possible à celle d'un widget Tk de base. (Voir Tk::options pour une description de ce comportement). Pour réaliser cela il faut définir les attributs que le composite accepte dans son ensemble. B Typiquement un widget aura un ou plusieurs appels semblables au suivant $composite->ConfigSpecs(-attribut => [where,dbName,dbClass,defaut]); dans sa méthode B. Lorsque B est appelé de cette manière (avec des arguments), les arguments sont utilisés pour construire ou augmenter/remplacer une table hash pour le widget. (on peut spécifier plus d'une paire I<-option>=EI dans un seul appel.) B, B et default sont utilisés uniquement par B décrit ci-dessous, ou pour répondre aux commandes de requête de configure. Ce peut être soit une des valeurs ci-dessous, ou bien une liste de telles valeurs entre crochets B<[]>. Les valeurs permises actuellement pour B sont : =over 4 =item B<'ADVERTISED'> applique B aux subwidgets I ("nommés" : voir Tk::mega). =item B<'DESCENDANTS'> applique B à tous les descendants, récursivement. =item B<'CALLBACK'> Lors de l'initialisation des attributs, effectue Cnew($valeur)> avant de stocker la valeur dans C<$composite-E{Configure}{-attribut}>. Ceci est approprié pour les attributs "-command => ..." qui sont pris en charge par le composite et ne sont pas transmis à un subwidget. (par exemple, B possède C<-yscrollcommand> qui lui permet d'avoir une scrollbar attachée.) Ceci devrait être le premier de plusieurs mots-clés de 'validation' (par exemple font, cursor, anchor, etc.) que le coeur de Tk rend spécial pour le code C. =item B<'CHILDREN'> applique B à tous les enfants. (les enfants sont les descendants immédiats d'un widget.) =item B<'METHOD'> appelle C<$cw-Eattribut(valeur)> C'est le cas le plus général. Il suffit d'avoir une méthode de la classe du composite portant le même nom que l'attribut. La méthode peut effectuer toute les validations et avoir tous les effets de bord que vous désirez. Il est probablement préférable de les 'mettre en file d'attente' en utilisant B pour obtenir des effets de bord plus complexes. =item B<'PASSIVE'> Stocke simplement la valeur dans C{Configure}{-attribute}> Cette forme est également le bon endroit pour les attributs que vous gérez uniquement à la création du composite. =item B<'SELF'> Applique B au widget (par exemple B) qui est à la base du composite. (C'est le comportement par défaut pour la plupart des attributs qui font qu'une simple Frame devient ce que vous en attendez.) Notez qu'une fois que vous avez spécifié B pour un attribut vous devez explicitement inclure 'SELF' dans la liste si vous voulez que les attributs s'appliquent au composite lui-même (ceci élimine les dangereux problèmes de récursion infinie). =item B<$reference> (blessed) Appelle B<$reference>-Econfigure(-attribut => valeur) Un cas courant est celui où B<$reference> est un subwidget. $reference peut aussi être le résultat de Tk::Config->new(setmethod, getmethod, args, ...); La classe B est utilisée pour implémenter tous les types de mot-clé ci-dessus. La classe possède les méthodes "configure" et "cget" ce qui permet au code de niveau plus élevé de I appeler simplement une de ces méthodes sur n'importe quel I. =item B Si l'on définit : $cw->ConfigSpecs( ... -option => [ { -optionX=>$w1, -optionY=>[$w2, $w3] }, dbname, dbclass, default ], ... ); alors $cw->configure(-option => valeur)>" a en réalité pour effet : $w1->configure(-optionX => valeur); $w2->configure(-optionY => valeur); $w3->configure(-optionY => valeur); =item B<'autrechaîne'> Appelle $composite->Subwidget('autrechaîne')->configure( -attribut => valeur ); Puisque ceci existe pour compatibilité ascendante avec Tk-b5, il est certainement mieux d'utiliser directement la référence au subwidget. Le seul cas où l'on devrait retenir cette forme est de fournir une couche d'abstraction supplémentaire - peut-être en ayant un subwidget 'courant' - ceci n'est pas prouvé. =item B C '-autreattribut' )> est utilisé pour rendre C<-alias> équivalent à C<-autreattribut>. Par exemple les alias -fg => '-foreground', -bg => '-background' sont fournis automatiquement (même s'ils ne sont pas toujours spécifiés). =back B $composite->ConfigSpecs($subwidget->ConfigSpecs); L'instruction ci-dessus génère une liste des arguments ConfigSpecs d'un I, un pour chaque option valide dans la classe de $subwidget, et délègue lesdites options à $subwidget. Voir Tk::Widget et la méthode ConfigSpecs de I. Dupliquer des ConfigSpecs de I et des ConfigSpecs de I peut amener des résultats indéfinis. B Après l'exécution de la méthode B, la méthode B est appelée. Ceci appelle $composite->ConfigSpecs; (sans arguments) qui retourne une référence à un hash. Les entrées du hash prennent la forme : '-attribut' => [ where, dbName, dbClass, défaut ] B ignore complètement 'where' (ainsi que l'entrée DEFAULT) et teste la base de données 'options' du widget, et si une entrée correspondant à dbName/dbClass est présente, -attribut => valeur est ajouté à la liste des options que B appliquera finalement au widget. De la même manière s'il n'y a pas de correspondance avec dbName/dbClass et que "défaut" est défini cette valeur par défaut sera ajoutée. Les entrées alias du hash sont utilisées pour convertir les valeurs spécifiées pour l'alias par l'utilisateur en valeurs pour le véritable attribut . B()B<-time Configure> Lorsque B reprend le contrôle, la liste des options fournies par l'utilisateur et celle provenant de B sont appliquées au widget au moyen de la méthode B ci-dessous. Les widgets sont d'autant plus flexibles et d'autant plus "Tk-like" qu'elles gèrent la majorité de leurs attributs de cette manière. B Une fois ceci effectué, le appels de la forme : $composite->configure( -attribut => valeur ); devraient ressembler à ceux de n'importe quel autre widget du point de vue du code de l'utilisateur final. B sera pris en charge par B de cette manière : $composite->ConfigSpecs; est appelé (sans arguments) et retourne une référence à un hash dans lequel on recherche B<-attribut>, si B<-attribut> n'est pas présent dans le hash alors on recherche B<'DEFAULT'> à la place. (Les alias sont essayés autant qu'il faut et entraînent une redirection vers l'attribut alias). Le résultat doit être une référence à une liste du type : [ where, dbName, dbClass, default ] à ce point nous nous intéressons seulement à I, qui renvoie vers une liste de références d'objet (éventuellement un seul) pour chaque $object->configure( -attribut => valeur ); B<éval>ué. B $composite->cget( '-attribut' ); Ceci est traité par B d'une manière similaire à configure. Actuellement si I est une liste de plus d'un objet il est ignoré complètement et la valeur "cachée" dans $composite->{Configure}{-attribut} est renvoyée. =head1 AVERTISSEMENTS Il est dans l'intention de l'auteur de porter autant de widgets composites "Tix" qu'il est possible. Le mécanisme décrit ci-dessus doit évoluer pour rendre cela possible, toutefois maintenant que les alias sont gérés je pense que ce qui est décrit ici est suffisant. =head1 VOIR AUSSI Tk::composite, Tk::options =head1 TRADUCTION Jean-Pierre Vidal jeanpierre.vidal@free.fr =head1 RELECTURE Pas de relecture pour le moment