NOM

Tk::composite - Créer une nouvelle classe de widget composite


SYNOPSIS

  package Tk::MyNewWidget;
  use Tk:widgets qw/ liste de widgets Tk /;
  use base qw/ Tk::Frame /;      # ou Tk::Toplevel
  Construct Tk::Widget 'MyNewWidget';
  sub ClassInit { 
    my ( $class, $mw ) = @_;
    #... par exemple, mettre ici les liaisons de classe ... 
    $class->SUPER::ClassInit($mw); 
  }
  sub Populate { 
    my ( $self, $args ) = @_;
    my $flag = delete $args->{-flag}; 
    if ( defined $flag ) { 
      # prendre en compte -flag => xxx ce qui ne peut être fait 
      # qu'au moment de la création 
      # le "delete" ci-dessus assure que new() n'entraînera pas 
      # un $cw->configure(-flag => xxx); 
    }
    $self->SUPER::Populate( $args );
    $self = $self->Component( ... );
    $self->Delegates( ... );
    $self->ConfigSpecs( 
      '-cursor'    => [ SELF, 'cursor', 'Cursor', undef ], 
      '-something' => [ METHOD, dbName, dbClass, default ], 
      '-text'      => [ $label, dbName, dbClass, default ], 
      '-heading'   => [ {-text=>$head}, heading, Heading, 'My Heading' ],
     ); 
  }
  sub something { 
    my ( $self, $value ) = @_; 
    if (@_>  1) { 
      # l'initialiser 
    } 
    return # valeur courante 
  }
  1;
  __END__
  =head1 NAME
  Tk::Whatever - un widget whatever
  =head1 SYNOPSIS
  use Tk::Whatever;
  $widget = $parent->Whatever(...);
  =head1 DESCRIPTION
  ...


DESCRIPTION

L'idée qui sous-tend un widget composite est de créer un widget de plus haut niveau, parfois appelé un ``super-widget'' ou un ``meta-widget''. Très souvent, un composite sera construit à partir d'autre widgets en les utilisant, plutôt qu'en les spécialisant. Par exemple, le widget composite distribué LabEntry est composé d'un Entry et d'un Label ; ce n'est en aucun cas une sorte de Label, pas plus qu'une sorte d' Entry.

Le principal travail d'un widget composite consiste à créer des subwidgets, distribuer les options de configuration aux bons subwidgets et gérer les options de configuration spécifiques au widget composite.


DETAILS GLORIEUX

Selon votre connaissance de Perl/Tk, cette section vous éclairera ou vous plongera dans la plus grande confusion.

Widget Composite

Puisque Perl/Tk utilise largement une approche orientée-objet, il n'est pas surprenant que la création d'un composite s'effectue au moyen d'une methode new(). Toutefois, le composite ne définit habituellement pas lui-même une méthode new() : il suffit généralement qu'il hérite cette méthode de Tk::Widget.

Voici ce qui se passe lorsque le composite utilise

  use base qw/ Tk::Frame /;  # ou Tk::Toplevel

pour spécifier sa chaîne d'héritage. Pour terminer l'initialisation du widget, il doit appeller la méthode Construct de la classe Widget. Cete méthode accepte le nom de la nouvelle classe à créer, c'est à dire le nom de package de votre widget composite :

  Construct Tk::Widget 'MyNewWidget';

Ici, MyNewWidget est le nom de package (une sorte de classe de widget). Ceci définit une méthode constructeur pour MyNewWidget, nommée normalement d'après la classe du widget. L'instanciation de ce composite dans le code client pourrait ressembler à ceci :

  $mw = MainWindow->new;    # Crée une fenêtre principale
  $self = $mw->MyNewWidget();  # Crée une instance du 
          # widget composite MyNewWidget

Lorsqu'un composite est instancié par le code client, Tk::Widget::new() est invoqué via le constructeur de classe du widget. Cette méthode new appelle

  $self->Populate(\%args);

%args représentent les arguments passés au constructeur du widget. Notez que Populate reçoit une référence au hash contenant les arguments.

Populate est typiquement définie dans la classe composite (le package), qui crée les widgets caractéristiques de la classe.


B<Création des subwidgets>

La création des subwidget est généralement effectuée dans Populate(). Le composite appelle habituellement la méthode constructeur du subwidget soit directement, pour les subwidgets ``privés'', soit indirectement au travers de la méthode Component pour les subwidgets devant être publiés vers le client.

Populate doit appeler Delegates pour rediriger les appels aux méthodes des subwidgets choisis. Pour des composites simples, la plupart, sinon la totalité des méthodes, sont redirigées vers un seul subwidget - par exemple ScrListbox redirige toutes les méthodes vers [le coeur de] Listbox, et de cette manière $composite->get(...) appelle $listbox->get(...).

Définir les options d'un méga-widget

Populate doit aussi appeler ConfigSpecs() afin de spécifier la manière dont les options de style ``configure'' seront traitées dans le composite. A la sortie de Populate, la méthode Tk::Frame::ConfigDefault examine les entrées de ConfigSpecs et peuple le hash %$args avec les options par défaut à partir des ressources X (.Xdefaults, etc.).

Lors du retour de Populate vers Tk::Widget::new(), un appel de $self->configure(%$args) est exécuté, initialisant *toutes* les options.


VOIR AUSSI

Tk::ConfigSpecs Tk:mega Tk::Derived


TRADUCTION

Jean-Pierre Vidal jeanpierre.vidal@free.fr


RELECTURE

Pas de relecture pour le moment