=head1 NOM

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

=head1 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

  ...

=head1 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 B<utilisant>, plutôt
qu'en les spécialisant. Par exemple, le widget composite distribué B<LabEntry>
est I<composé> d'un B<Entry> et d'un B<Label> ; ce n'est en aucun cas une
I<sorte de> B<Label>, pas plus qu'une I<sorte d'> B<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.

=head1 DETAILS GLORIEUX

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

B<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
I<B<new()>>. Toutefois, le composite ne définit habituellement pas lui-même
une méthode I<B<new()>> : il suffit généralement qu'il hérite cette méthode de
B<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 B<Construct> de la classe B<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, B<MyNewWidget> est le nom de package (une sorte de B<classe> de
widget). Ceci définit une méthode constructeur pour B<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, C<Tk::Widget::new()> est
invoqué via le constructeur de classe du widget. Cette méthode B<new> appelle

  $self->Populate(\%args);

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

B<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 I<B<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 B<Component> pour les subwidgets devant être publiés vers le client.

B<Populate> doit appeler B<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
B<ScrListbox> redirige toutes les méthodes vers [le coeur de] B<Listbox>, et
de cette manière I<$composite>-E<gt>B<get>(...)  appelle
I<$listbox>-E<gt>B<get>(...).

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

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

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

=head1 VOIR AUSSI

Tk::ConfigSpecs Tk:mega Tk::Derived

=head1 TRADUCTION

Jean-Pierre Vidal jeanpierre.vidal@free.fr

=head1 RELECTURE

Pas de relecture pour le moment