______________________________________________________________________
Le lundi 14 septembre,
  jnmrclgrnd <jnmrclg...@free.fr> a écrit :

> > Ça doit pouvoir se faire avec un invariant.
> > http://svn.zope.org/zope.schema/trunk/src/zope/schema/validation.txt?rev=96012&view=markup
> >  
> >
> 
> Ah tiens, oui, j'ai vu passer ça quelque part... je vais creuser.

Sans aucun doute, les invariants sont parfaitement adaptés à ce genre
de cas, pour lesquels les contraintes ne sont pas propres à un seul
attribut mais à une combinaison plus complexe entre plusieurs attributs
d'une même interface.
Ça peut donner quelque chose comme ça :

    from zope.interface import Interface, invariant, Invalid

    class IClient(Interface):

        @invariant
        def checkPhone(self):
            if (self.genre == 'Femme') and \
               not self.telephone:
                raise Invalid, _("Phone required !!")

L'avantage d'utiliser les invariants est qu'il sont pris en charge
automatiquement par les toolkits de gestion de formulaires existants
(zope.formlib, z3c.form...).


> Et comme je suis en train de continuer la lecture de Philip W., je
> suis tombé sur la notion d'event... peut-être puis-je créer un event
> qui fait un truc du genre : if genre==u'Femme', déclencher un adapter
> de la classe Client qui demande un n° de téléphone. Je dis ça, mais
> c'est encore très conceptuel...
> 
> Et pour mon appli Eticoto, je me dis que la sélection du pays peut 
> déclencher un event qui orientera la suite de l'instanciation vers 
> l'adapter correspondant au format d'adresse du pays... A creuser (je 
> passe chez Jardiland ce soir pour acheter des pelles et des pioches)
> 
> Merci pour cette réponse, Christophe ! J'espère arriver au terme de
> ma quête pour ces histoires d'étiquettes : je promets à la liste un
> petit vade mecum de la construction de l'appli en question, ainsi
> qu'une doc de pro !

La première étape peut effectivement être de déclarer des adaptateurs
nommés de IClient vers IAdresse ; ça doit pouvoir marcher si :
 - IAdresse est une interface de marquage, ne comportant que les champs
   communs des adresses (voire aucun !)
 - pour chaque format d'adresse spécifique, on aura une interface
   spécifiques héritée de IAdresse, avec un adaptateur correspondant de
   IClient vers IAdresse nommé en fonction de la langue de l'adresse ;
   une méthode de IAdresse (getInterface ?) doit permettre de récupérer
   l'interface réellement implémentée ; il faut également un adaptateur
   par défaut qui prenne en charge les cas des adresses "standard".

Bon, j'ai pas réfléchi très longtemps là dessus mais ça doit le faire.
Et une fois qu'on a l'adresse et son interface réelle, il est assez
facile de faire une redirection vers un formulaire de saisie générique
prenant en paramètre l'interface réelle de l'adresse.

Par ailleurs, je ne pense pas que l'utilisation des événements soit
adaptée à ce genre de problématique ; ils sont utiles pour définir des
actions de mise à jour qui se déclenchent automatiquement lorsque
certains événements interviennent sur des objets (création,
modification...) ; mais ils ne sont pas orientés "interface
utilisateur".

A+
Thierry

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

_______________________________________________
zope3-french-user mailing list
zope3-french-user@lists.afpy.org
http://lists.afpy.org/mailman/listinfo/zope3-french-user

Répondre à