Que peut-on faire avec Zope 3.3 ?

Posté par (page perso) . Modéré par j.
Tags :
1
21
oct.
2006
Python
À l'occasion de la sortie de Zope 3.3.0 voici une micro présentation permettant d'appréhender rapidement ce qu'offre Zope 3 pour le développeur web.

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).
  • # des PAGES web

    Posté par (page perso) . Évalué à 0.

    A mon avis, le HTML et ses déscendants comme XHTML sont conçus à la base pour faire des pages, c'est à dire du texte structuré et avec des hyperliens, rien de plus.
    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 . Évalué à 7.

      pour transformer les pages xhtml en page html automatiquement et mettre le site en ligne.
      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 . Évalué à 5.

      Si je comprends bien, Gopher te manque?
      • [^] # Re: des PAGES web

        Posté par (page perso) . Évalué à 5.

        Je ne connais pas bien Gopher, j'en avais juste entandu parler ici où là.

        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 (page perso) . Évalué à 6.

      Une question liée se pose également, c'est celle de la performance (no troll inside).

      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 . Évalué à 5.


        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 ?


        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 . Évalué à 5.

      A mon avis, le HTML et ses déscendants comme XHTML sont conçus à la base pour faire des pages, c'est à dire du texte structuré et avec des hyperliens, rien de plus.
      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 ...
      Les formulaires font partie du standard html depuis belle lurette.

      C'est quoi le but d'une page web au fond ? structurer du contenu, non ?

      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 (page perso) . Évalué à 4.

        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.


        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.

        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...


        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 . É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


          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...

          Et aussi, cela risque de te déplaire, mais je préfère le NNTP


          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 (page perso) . Évalué à 2.

            NNTP te permet très bien d'archiver les posts ... Ce n'est qu'un protocole, derrière tu met le srveur que tu veux.

            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 . Évalué à 2.

              NNTP te permet très bien d'archiver les posts ...


              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 (page perso) . Évalué à 5.

    Hello,

    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 (page perso) . Évalué à 8.

      1- Question perfs, tout depend de l'appli qu'on fait tourner dessus. Plone n'est pas vraiment un exemple de rapidité mais il faut comparer avec des CMS offrant la même richesse fonctionnelle et il y en a pas beaucoup.

      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 (page perso) . Évalué à 5.

    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 ?

      Posté par . Évalué à 6.

      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 ?

        Posté par . Évalué à 1.

        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 ?

          Posté par . Évalué à 4.

          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 ?

            Posté par (page perso) . Évalué à 1.

            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 ?

              Posté par . Évalué à 3.

              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 ?

            Posté par . Évalué à 2.

            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 ?

      Posté par . Évalué à 4.

      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 ?

      Posté par (page perso) . Évalué à 1.

      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 ?

        Posté par . Évalué à 1.

        Et le ducktyping, c'est pour les chiens? ;)
        • [^] # Re: Interface en Python ?

          Posté par (page perso) . Évalué à 4.

          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.
  • # et Zope vs ezPublish ?

    Posté par (page perso) . Évalué à 4.

    En lisant le descriptif, il me semble reconnaître des principes appliqués par ez Publish (l'usine à gaz en PHP), la notion d'objet plutôt que de pages. J'ai pu assister aux graves douleurs de le mise en forme d'un site avec ez, il y a-t-il des connaisseurs des deux mondes qui peuvent donner leur expérience des deux mastodontes.

    D'avance, merci.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.