Logiciel : Que peut-on faire avec Zope 3.3 ?
Posté par ccomb (Jabber id, page perso, ). Modéré le 21 octobre 2006.
Zope est un serveur d'application web écrit en Python. Les éléments (documents, images, templates ..) sont des objets stockés dans la base de données objets (ZODB) et sont publiés sur différents protocoles : HTTP, FTP, WebDAV, XML-RPC. On ne parle plus en termes de pages mais d'objets auxquels on applique des méthodes (vue, action, etc.). L'ensemble peut être entièrement piloté par une interface Web.
Zope 3 est une réécriture complète de Zope 2 sous forme d'une architecture à base de composants. De nombreuses versions sont apparues depuis 3 ans et il est aujourd'hui utilisable et utilisé en production (par ex. le Launchpad d'Ubuntu ou le projet SchoolTool).
Zope 3 permet d'aborder la puissance de Zope de manière plus directe et plus propre. Il est plus cohérent, plus homogène, plus léger et de plus en plus simple au fil des versions. Il est conçu dès le départ pour les projets complexes, mais il est maintenant possible de faire de petits sites et c'est probablement la meilleure façon d'apprendre progressivement. Néanmoins, il est préférable d'être à l'aise avec la programmation objet et les design patterns. La modularité et la souplesse de Zope 3 rendent la plupart de ses composants indépendants du serveur d'application. À l'opposé, il est possible de réutiliser des produits externes sans les modifier grâce à l'écriture d'adaptateurs. L'accent est mis sur les notions d'interfaces, de tests unitaires et fonctionnels, et d'autodocumentation.
Vous trouverez dans la suite de l'article une liste des fonctionnalités de Zope 3, ainsi que deux exemples simples et concrets d'utilisation des technologies zope : la ZODB et les ZPT.
Zope 3 est sous licence ZPL 2, compatible avec la GPL.
![[fr]](../images/fr.png)
Une présentation un peu plus complète (2349 hits)![[en]](../images/en.png)
Zope 3.3.0 (633 hits)-
La nouvelle FAQ (156 hits)
-
Liste de diffusion EN (89 hits)
-
Liste de diffusion FR (245 hits)
-
Un recueil de liens (362 hits)
> Lire la dépêche (30 commentaires, moyenne: 3,6).
Vous avez demandé le commentaire #767302.
Run by 
Cette page a été générée par Templeet en 0.0663s (dont 0.0068 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Interface en Python ?
Je viens de voir que ce zope propose "la notion d'interface" à python (et l'introspection de celle ci). Python est un langage multi-héritage si je ne m'abuse, quel est l'interet d'une telle fonctionnalité dans un langage de ce type ?
[^]Re: Interface en Python ?
Si je ne m'abuse, la notion d'interface n'est pas uniquement un paliatif à l'absence d'héritage multiple (au hasard : en Java).
[^]Re: Interface en Python ?
Il faudrait que tu developpe ton post car Java n'ayant justement pas l'héritage multiple, c'est difficile de voire dans quel cas les interfaces ne sont pas un paliatif..
Je pense que c'est uniquement dans les langages qui ont l'héritage multiple que l'on peut voir si les interfaces (autrement dit l'héritage de classe abstraite) sont utile.
[^]Re: Interface en Python ?
Il faudrait que tu developpe ton post car Java n'ayant justement pas l'héritage multiple, c'est difficile de voire dans quel cas les interfaces ne sont pas un paliatif..
Bof. Je disais juste que le fait d'être présentées comme palliatif au manque d'héritage multiple de Java ne les cantonne pas à cette seule utilisation.
Leur signification "profonde" (tel objet se conforme à tel protocole) est subtilement différente de celle d'un héritage (tel objet est un cas particulier de tel autre), fut-il multiple (tel objet est à la fois un cas particulier de tel objet, mais aussi de cet autre).
Qu'on puisse interchanger les deux au niveau implémentation (et encore, c'est plus que discutable) est une chose, qu'elles aient la même signification conceptuelle en est une autre.
Exemple type : les tableaux et les listes. On peut tout à fait se demander quel est l'intérêt d'avoir une implémentation de listes dès lors qu'on a des tableaux (et qu'on peut rajouter du code par-dessus pour simuler une liste). Reste que ça n'est pas la même chose, et qu'on ne se pose généralement pas trop la question de la pertinence des listes.
[^]Re: Interface en Python ?
Tu penses donc, si j'ai bien compris que l'apport est uniquement "sémantique". Pourquoi pas :)
Sinon, il y a des langages ou les listes sont considérés comme des sous classes des tableaux, c'est pas une mauvaise chose, amha.
[^]Re: Interface en Python ?
Sinon, il y a des langages ou les listes sont considérés comme des sous classes des tableaux, c'est pas une mauvaise chose, amha.
Tout dépend de la définition qu'on donne à "liste" et à "tableau", je présume. Parce qu'avoir une liste sous-classe du tableau C (attention, programming-fiction inside!), ça me ferait un peu mal aux fesses. Le seul point commun que je leur voit, c'est de contenir des données ordonnées. Mais ça s'arrète un peu là : ça fait court pour un sous-classage.
[^]Re: Interface en Python ?
Reste que ça n'est pas la même chose, et qu'on ne se pose généralement pas trop la question de la pertinence des listes.
C'est amusant comme remarque, parce que justement beaucoup de langages haut niveau (comme Python) unifient les deux.
[^]Re: Interface en Python ?
De ce que j'ai compris (je ne connais qu'un peu), la notion d'interface en Zope est à la base de la notion d'architecture à base composant.
En gros, ton code demande un objet qui implémente une interface et hop Zope te sort l'objet qui va bien suivant le contexte. C'est une méthode préféré à celle qui consisterai à donner un composant par "nom", l'interface étant censé décrire sémantiquement les propriétés de l'objets attendu. Autrement dit, c'est le contrat que doit satisfaire l'objet qui sera fournit par Zope lorsque l'application demandera tel composant.
Ceci permet de changer un composant par les fichiers de configuration (mais aussi depuis le code) et de remplacer un composant dans le futur.
[^]Re: Interface en Python ?
N'importe qu'elle classe Python/Zope peut implémenter une interface sans avoir à hériter d'une autre classe. L'avantage est de pouvoir faire 'Iintreface.isImplementedBy(obj)' pour vérifier que l'objet sur lequel on travaille est bien compatible avec la tâche que nous voulons lui faire faire.
[^]Re: Interface en Python ?
Et le ducktyping, c'est pour les chiens? ;)
[^]Re: Interface en Python ?
Les interfaces permettent de formaliser le ducktyping : ca permet entre autre de developper des composants pour un gros framework sans avoir a connaitre tous les details d'implementation de chaque composant du framework. Ca devient capital des que la base de code devient grande sinon on se retrouve vite avec un truc comme Zope2 avec des heritages de 40 classes dont certaines ont été implementées il y a 10 et que personnes n'ose plus toucher de peur de faire s'ecrouler le chateau de cartes.