Tk::ConfigSpecs - Définir le comportement de 'configure' pour les widgets composites.
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);
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.
Définir les ConfigSpecs pour une classe.
Typiquement un widget aura un ou plusieurs appels semblables au suivant
$composite->ConfigSpecs(-attribut => [where,dbName,dbClass,defaut]);
dans sa méthode Populate. Lorsque ConfigSpecs 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 -option=>valeur dans un seul appel.)
dbName, dbClass et default sont utilisés uniquement par ConfigDefault 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 [].
Les valeurs permises actuellement pour where sont :
Tk::Callback->new($valeur) avant de stocker la valeur dans
$composite->{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, Tk::Tiler possède
-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.
$cw->attribut(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 afterIdle pour obtenir des effets de bord plus complexes.
composite->{Configure}{-attribute}
Cette forme est également le bon endroit pour les attributs que vous gérez uniquement à la création du composite.
Un cas courant est celui où $reference est un subwidget.
$reference peut aussi être le résultat de
Tk::Config->new(setmethod, getmethod, args, ...);
La classe Tk::Config 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 toujours appeler simplement une de ces méthodes sur n'importe quel objet.
$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);
$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é.
ConfigSpecs( -alias => '-autreattribut' ) est utilisé pour rendre
-alias équivalent à -autreattribut. Par exemple les alias
-fg => '-foreground', -bg => '-background'
sont fournis automatiquement (même s'ils ne sont pas toujours spécifiés).
Déléguer toutes les options d'une classe de widget à un subwidget
$composite->ConfigSpecs($subwidget->ConfigSpecs);
L'instruction ci-dessus génère une liste des arguments ConfigSpecs d'un composite, 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 widget. Dupliquer des ConfigSpecs de composite et des ConfigSpecs de widget peut amener des résultats indéfinis.
Valeurs par défaut
Après l'exécution de la méthode Populate, la méthode ConfigDefault 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 ]
ConfigDefault 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 new 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 .
New()-time Configure
Lorsque new reprend le contrôle, la liste des options fournies par l'utilisateur et celle provenant de ConfigDefault sont appliquées au widget au moyen de la méthode configure 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.
Configurer les composites
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. configure sera pris en charge par Tk::Derived::configure de cette manière :
$composite->ConfigSpecs;
est appelé (sans arguments) et retourne une référence à un hash dans lequel on recherche -attribut, si -attribut n'est pas présent dans le hash alors on recherche '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 à where, qui renvoie vers une liste de références d'objet (éventuellement un seul) pour chaque
$object->configure( -attribut => valeur );
évalué.
Retrouver les attributs d'un composite
$composite->cget( '-attribut' );
Ceci est traité par Tk::Derived::cget d'une manière similaire à configure. Actuellement si where 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.
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.
Tk::composite, Tk::options
Jean-Pierre Vidal jeanpierre.vidal@free.fr
Pas de relecture pour le moment