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. Zope 3 offre entre autres :
- une gestion forte et complète de la sécurité
- Une base de données objet (ZODB)
- Un serveur web intégré
- Une architecture à composants
- L'ajout de la notion d'interfaces à python
- L'introspection et l'autodocumentation des classes et interfaces
- Des registres pour classer les composants par interface et par nom
- Un moteur de template XHTML (ZPT)
- Des vues associées aux objets
- Des viewlets comme composants des vues
- Des skins et des layers pour les vues
- La création et validation automatique des formulaires web
- La transmission d'événements entre objets (subscribers)
- Un langage de configuration en xml des composants (ZCML)
- Une interface web de gestion et de documentation (ZMI)
- La notion d'adapters pour relier des objets entre eux
- Deux modules de workflow (wfmc et hurry.workflow)
- L'indexation
- Des méta-données pour tous les objets. (Dublin-Core par défaut)
- Une API de dépréciation
- L'internationalisation complète avec gestion native de l'Unicode
- La gestion des préférences utilisateurs
- Les tests unitaires et fonctionnels
- Une conception qui met l'accent sur les Design Patterns et l'Extreme Programming
- De nombreux composants pour tous les usages
Exemple d'utilisation de la base de données objet :
La base de données objet (ZODB) permet d'organiser des objets de manière arborescente : certains objets, comme l'objet Folder, peuvent contenir d'autres objets. Le stockage des données se fait sans effort et de manière transparente : il n'y a pas de requête à faire, les objets stockés dans la base sont directement accessibles dans le code.
- Par exemple pour créer un objet Machin et l'enregistrer dans la base de données sous le dossier "folder", il suffit d'écrire
machin = Machin()
folder['machin']=machin
- Pour le récupérer :
monmachin = folder['machin']
- Pour l'effacer de la base de données :
del folder['machin']
- Pour modifier son titre :
folder['machin'].title = u'titre'
Le seul prérequis est que Machin soit héritée de Persistent.
Exemple de titre HTML créé dynamiquement dans une page
Le module Zope Page Template permet d'écrire des pages templates en XHTML en conservant la validité XML. Ceux-ci peuvent donc être envoyés à un graphiste ou être édités de manière transparente dans un éditeur wysiwyg.
Pour créer un titre dynamiquement dans une page html, il suffit d'écrire :
<h1 tal:content='objet/titre'>mon titre</h1>
La partie « tal:content » indique de remplacer le contenu de la balise h1, c'est-à-dire « mon titre », par l'expression fournie.
Et l'expression « objet/titre » permet d'accéder à l'attribut « titre » de l'objet « objet ».
Zope 2 offrait un système de macros permettant de créer des templates de templates, mais dans Zope 3 un système plus souple et plus puissant que les macros ont été créés : les Viewlets et les Viewlet Managers. Des démos de Viewlets et Viewlets Managers et d'autres composants sont disponibles (à installer dans une instance Zope).
Aller plus loin
- Une présentation un peu plus complète (73 clics)
- Zope 3.3.0 (19 clics)
- La nouvelle FAQ (1 clic)
- Liste de diffusion EN (4 clics)
- Liste de diffusion FR (14 clics)
- Un recueil de liens (20 clics)
# des PAGES web
Posté par Mildred (site web personnel) . Évalué à 0.
Ce que je regrette dans l'évolution du web c'est que cela s'est perverti et que maintenant on fait des interfaces en xHTML. Des menus, des boîtes ...
Ce que je rêve pour le web, c'est un web sans tableaux pour la présentation, sans feuilles de style imposées ... Un web où il y aurait un nouveau type de document décrivant la structure d'un site et présenté par le navigateur dans la forme préférée par l'utilisateur, au lieu d'avoir pour chaque site un système de menus différent.
Un seb où on puisse se passer de la feuille de style du site pour choisir la sienne, qui serait valable pour tous les sites, ou aucune, tout en concervant une facilité de navigation.
Un web où les balises link dans le head soient présentées par le navigateur à l'utilisateur. (je veux ça dans epiphany, safari et de préférence par défaut dans firefox et peut être konqueror (il le fait peut être déjà par défaut)).
mais ce n'est pas avec les évolution actuelles (WEB2, AJAX, ...) qu'on s'en approche, je n'en ai pas l'impression.
Je me rapelle la page d'un projet sur sourceforge où dans la FAQ il y avait une question du style "Pourquoi ce site est-il moche ?", le site n'utilisait pas de feuilles de style, et encore moins des tableaux ...
Pourquoi ? Car votre navigateur a choisi une feuille de style par défaut moche, changez-la et vous aurez un joli site.
Malhereusement, cette solution n'est pas applicable car si on la change, on va se retrouver aec d'autres sites qui s'attendent à des paramètres par défaut qui ne seront pas présents, et je pense qu'un grand nombre de site seront inutilisables.
C'est quoi le but d'une page web au fond ? structurer du contenu, non ?
Au moment où j'ai réalisé cela, j'ai changé ma manière de concevoir les sites web. D'un système compliqué en php, je suis passée à des pages xhtml statiques mises à jour periodiquement par une tache cron pour transformer les pages xhtml en page html automatiquement et mettre le site en ligne.
[^] # Re: des PAGES web
Posté par dab . Évalué à 7.
J'ai saisi à peu près tout ton message, mais là je comprends plus.
Il me semble que tu souhaites que la partie css soit définie par ton browser ( tout du moins pour les balises classiques) et tu enchaînes par le fait que tu sois passée du xhtml au html.
J'avoue ne pas réellement saisir.
Pourquoi le fait de vouloir structurer du contenu implique une "régression" xhtml -> html
[^] # Re: des PAGES web
Posté par bidibulle . Évalué à -6.
Il va y avoir des fou rires terribles dans bien des réunions, je crains fort...
[^] # Re: des PAGES web
Posté par Mildred (site web personnel) . Évalué à 4.
http://httpd.apache.org/docs/2.0/content-negotiation.html
[^] # Re: des PAGES web
Posté par jm trivial (site web personnel) . Évalué à 5.
[^] # Re: des PAGES web
Posté par Jean-Philippe (site web personnel) . Évalué à 7.
[^] # Re: des PAGES web
Posté par reno . Évalué à 4.
[^] # Re: des PAGES web
Posté par Larry Cow . Évalué à 5.
[^] # Re: des PAGES web
Posté par Mildred (site web personnel) . Évalué à 5.
http://fr.wikipedia.org/wiki/Gopher
http://en.wikipedia.org/wiki/Gopher_protocol
... (lecture)
C'est un protocole qui à l'air intéressant, mais apparament abandonné. Et aussi, quelque chose me dérange un peu, tout le texte présent dans les menus sont urlencodés ...
Coté menus, j'imaginais plutôt un fichier RDF (par exemple) à la racine du site qui décrirait toutes les pages su site permettant au navigateur d'en afficher la structure.
Ou alors que chaque page web soit associée à une page de menu affichée par exemple dans une sidebar qui décrirait la section qu'on est en train de visiter et ferait des liens vers les sous-pages. La sidebar afficherait aussi les informations trouvées dans la page web au niveau des baliss meta par exemple. Et les liens des balises link.
Il existe une extension firefox permettant d'avoir un menu hiérarchique du site, malhereusement, j'utilise epiphany ... et il manque a mon avis un standard à ce niveau :
- https://linuxfr.org/~mildred/19352.html
- http://navibar.oaklett.org/ (le site à l'air d'être indisponnible)
[^] # Re: des PAGES web
Posté par Xavier Verne (site web personnel) . Évalué à 6.
Je lis que l'affectation d'une variable passe par une requête dans la base ZODB...Un pointeur pour expliquer cette partie dans l
Et effectivement, le modèle qui consiste à dire que chaque page est un objet est séduisant, mais en pratique ça sert à quoi ?
Est-ce qu'on peut par exemple avoir une sortie pdf ou odf de l'objet automatiquement puisque c'est simplement un autre affichage de la page résultat ?
[^] # Re: des PAGES web
Posté par Alex G. . Évalué à 5.
Ouip, mais plus précisément c'est le fait d'avoir des vues et l'adaptation qui le permettent. Si j'ai bien compris, tu fait un objet qui est une vue d'un type objet (adapte l'objet) pour une interface, par exemple "vue PDF". Si l'on demande la vue PDF de l'objet, Zope utilise ton adaptater avec l'objet PDF pour faire le PDF.
Ceci peut permettre d'avoir un adaptater PDF général par exemple pour les objets qui répondent à l'interface "objet texte" et de spécialiser l'adaptateur (par héritage par exemple) pour les objets "objet texte avec plan".
Le fait de n'avoir que des objets te permet surtout de tout stocker de manière homogène (ZODB), de pouvoir utiliser l'héritage, de faire des tests unitaires....
[^] # Re: des PAGES web
Posté par ragoutoutou . Évalué à 5.
Pas selement ça... un peu d'ouverture d'esprit te fera réaliser qu'on peut faire bien plus. Par exemple, mettre des systèmes de communication structurées sous forme de forum... comme celui-ci qu n'existerait pas si tout le monde adhérait à ta vision restrictive du rôle de la page web.
Tant qu'à faire, si on te suis, autant balancer le xml à l'utilisateur et le laisser se démerder pour le transformer en un truc lisible...
[^] # Re: des PAGES web
Posté par Mildred (site web personnel) . Évalué à 4.
Pour les forums en ligne, je préfère largement des langages comme le XUL qui ne sont malhereusement pas encore normalisés. A mon avis c'est bien plus adapté.
Et aussi, cela risque de te déplaire, mais je préfère le NNTP / newsgroups. Il y a un seul inconvénient, c'est que ce n'est pas toujours aussi joli que les webforums (avatars, mise en page HTML). Mais je préfèrerais vraiment un NNTP amélioré qu'un webforum.
Le problème des webforums, c'est que tu ne maîtrise pas ce que tu y fais. Surtout lorsque le webforum en question ne te permet pas de t'alerter par mail lors d'une réponse (vécu). Alors que le NNTP se fait dans un logiciel à toi que tu peux configurer comme tu veux.
C'est déjà plus ou moins le cas, et ce n'est pas le rôle de l'utilisateur mais du navigateur web ! Tu crois qu'il fait quoi mon epiphany à part me présenter joliment des fichiers SGML (plus ou moins valides) ?
[^] # Re: des PAGES web
Posté par ragoutoutou . Évalué à 4.
Entre écrire son interface en HTML qui est supporté très largement et XUL qui reste un langage non supporté par I.E. et donc inapplicable dans la majorité des entreprises. Pour la réalisation d'applications web, XUL reste le plus puissant, mais
Quitte donc à faire des applications web, autant utiliser ce bon vieil xhtml qui, si il n'est pas totalement fait pour ce boulot, dispose tout de même de fonctionnalités exploitables.
De plus, nombreuses sont les applications qui n'ont pas besoin du niveau de complexité de xul...
Bien que j'apprécie énormément le NNTP, je suis plutôt partisant de systèmes où l'information est mieux structurée.
Pouvoir, au sein d'une même interface, accéder à des informations liées en utilisant un seul et même protocole est un plus indéniable.
Enfin, la volatilité du NNTP en fait un système peu recommendable pour la mise en place de bases de connaissance en ligne.
Le NNTP est en outre inadapté pour des systèmes de suivi de problèmes, de vente en ligne, de rapports temps-réel,...
Le sites web dynamiques permettent de dépasser le stade de la simple consultation de données, ils permettent un dialogue avec l'utilisateur.
[^] # Re: des PAGES web
Posté par Mildred (site web personnel) . Évalué à 2.
Je le sais bien, j'ai créé un serveur NNTP pour faire une paserelle avec un webforum. le problème, c'est que j'ai abandonné car :
- il y aait beaucoup de requetes récursives et j'avais peur de générer trop de traffic, même si je mettais tout en cache
- et surtout mon client NNTP (sylpheed) n'est pas trop prévu pour les messages HTML
mais si tu s un client NNTP qui permet d'afficher les messages html, tu peux très bien le brancher sur un serveur qui mémorise les messages, ce n'est pas interdit pas le protocole.
[^] # Re: des PAGES web
Posté par ragoutoutou . Évalué à 2.
A condition d'avoir ton propre serveur NNTP...
Le NNTP est loin d'être répandu chez les hébergeurs classiques, et représente donc une solution peu accessible pour le commun des mortels (tout le monde n'a pas un serveur dédié).
Donc dans la majorité des cas de sites web non-commerciaux, le NNTP n'est pas une possibilité technique, et heureusement que les forums http existent (et puis ça s'insère tout de même mieux dans un site) ...
# Question perfs ?
Posté par Médéric RIBREUX (site web personnel) . Évalué à 5.
petite question rapide: ça donne quoi en terme de perfs ? Les essais que j'avais fait (Zope 2.3, celui de la sarge) à l'époque m'avait tout simplement fait fuir: le temps de génération des pages était trop long et l'espace mémoire occupé m''inquiétait fortement. L'application qui tournait dessus était Plone.
Finalement, j'ai opté pour une solution plus légère (basée sur PHP) et j'ai gardé mon serveur en l'état !
Maintenant, si on me dit que Zope 3 est plus léger, je referais bien quelques benchs.
Autre question: ZODB peut-il être comparé à Hibernate ?
[^] # Re: Question perfs ?
Posté par Olivier Grisel (site web personnel) . Évalué à 8.
2- Hibernate est un mapper Objet / Base relationnelle (ORM en anglais). La ZODB est une base objet pure : il n'y a pas de notion de tables / champs ... En pratique l'approche ZODB est plus souple pour le programmeur mais tolere generalement moins bien les acces concurrents.
Dans le monde python, l'equivalent de Hibernate serait plutot SQLAlchemy : http://www.sqlalchemy.org/ . Le tutoriel est trés bien fait donne une bonne idée de comment fonctionne un ORM : http://www.sqlalchemy.org/docs/tutorial.myt
Le principal problème si on veut faire fonctionner SQLAlchemy avec Zope 3 c'est de faire correspondre les transactions Zope avec les transactions de la base de donnée gérée par SQLAlchemy (pour les base transactionnelle comme postgresql par exemple). Heureusement la communauté est pleine de resource et fournit des solutions toutes prètes ou presque comme ZAlchemy : http://svn.zope.org/z3c.zalchemy/trunk/src/z3c/zalchemy/READ(...)
Il y a aussi SQLObject et SQLOS mais en perte de vitesse par rapport a SQLAlchemy / ZAlchemy.
# Interface en Python ?
Posté par bastien (site web personnel) . Évalué à 5.
[^] # Re: Interface en Python ?
Posté par Larry Cow . Évalué à 6.
[^] # Re: Interface en Python ?
Posté par reno . Évalué à 1.
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 ?
Posté par Larry Cow . Évalué à 4.
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 ?
Posté par bastien (site web personnel) . Évalué à 1.
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 ?
Posté par Larry Cow . Évalué à 3.
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 ?
Posté par Antoine . Évalué à 2.
C'est amusant comme remarque, parce que justement beaucoup de langages haut niveau (comme Python) unifient les deux.
[^] # Re: Interface en Python ?
Posté par Alex G. . Évalué à 4.
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 ?
Posté par Encolpe DEGOUTE (site web personnel) . Évalué à 1.
[^] # Re: Interface en Python ?
Posté par Larry Cow . Évalué à 1.
[^] # Re: Interface en Python ?
Posté par Olivier Grisel (site web personnel) . Évalué à 4.
# et Zope vs ezPublish ?
Posté par Yoan B (site web personnel) . Évalué à 4.
D'avance, merci.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.