Impec : c'est bien ce qu'il me semblait donc. Pas obligatoire, mais propre et utile pour 2 choses principales : le tri (par les contraintes) et les URL. Donc à utiliser dès maintenant, même pour de sprojets simples.

Pour mon exemple d'étiquettes, je vais avoir le pb du formatage par pays : les adresses n'auront pas du tout le même schéma d'un pays à l'autre. Donc stocker chaque client dans un folder par pays, et générer un formulaire d'après le pays d'origine, ça ne pourra se faire qu'en passant par des container...

Ça a l'air facile, comme ça, mais j'appréhende un peu le codage :-[

Merci pour ces éclairages succinct et efficaces ! :-*

JMarc

PS : c'ets marrant, j'étais just ene trian de lite le chapitre en question (moi j'ai la 3ème édition ! ;-) )
Thierry Florac a écrit :
______________________________________________________________________
Le vendredi 11 septembre,
  jnmrclgrnd <jnmrclg...@free.fr> a écrit :

  
Ahhh de la doc en français pour néophyte ! Bravo pour ces
explications qui m'éclairent beaucoup !

OK pour le concept de conteneur. La question est alors : faut-il (au
sens obligation, bonne pratique) prévoir pour chaque Content un
Container ? Est-ce qu'une interface doit toujours être reprise par un
container ? En fait, c'est cela qui me chiffone : certains exemples
d'appli l'utilisent, d'autres non. En particulier, je n'ai pas de
(ICOntainer) dans le WorldCookery de Philip W., alors qu'il y en a un
dans le BookMarker sus sité...
    
______________________________________________________________________


Bonjour,

J'ai retrouvé une trace des conteneurs dans le livre de Philip W., page
287 par exemple de la seconde édition ;-)

L'utilisation de conteneurs, au sens propre du terme, n'est pas
obligatoire ; mais alors me dira-t-on, tous ces objets que l'on crée,
de toute façon il faudra bien les stocker quelque part !!
Les conteneurs (qui implémentent l'interface IContainer) fournissent
quelques avantages :
 - comme évoqué dans mon message précédent, ils fournissent déjà des
   interfaces permettant de gérer finement les permissions d'accès en
   lecture et en écriture ;
 - ils supportent des contraintes liées aux interfaces que les objets
   qu'ils peuvent contenir doivent fournir ;
 - ils prennent déjà en charge la gestion des règles de nommage des
   objets qu'ils contiennent, via le support de l'interface
   INameChooser ;
 - au final, ils sont très utiles pour définir des hiérarchies d'objets
   (genre dossiers/sous-dossiers), notamment lorsque l'on souhaite
   accéder à chaque objet spécifiquement via une URL simple (ça a l'air
   bête, mais c'est l'un des trucs que je préfère dans les sites sous
   Zope : pas besoin de se prendre la tête pour générer de jolies
   URLs ;-) )
 - ils prennent déjà quasiment nativement en charge des protocoles
   autres que HTTP, tels que FTP ;
 - ils ont le mérite d'exister !

Maintenant, bien évidemment, rien n'interdit de stocker des objets dans
des propriétés qui n'implémentent pas ces interfaces, tels qu'une
liste, un dictionnaire ou un BTree ; le choix du mode d'implémentation
pourra dépendre, entre autres :
 - du modèle UML et du cycle de vie des différents objets associés ;
 - du nombre d'objets à prendre en charge
 - du mode d'accès à ces objets en termes d'interface utilisateur (rien
   n'interdit de définir des URLs simples pour des objets planqués
   ailleurs que dans des conteneurs, mais il faudra alors redéfinir
   quelques adaptateurs).

À+
Thierry

  

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

Répondre à