article de presse - Cap Data Consulting
article de presse - Cap Data Consulting
article de presse - Cap Data Consulting
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
T echnologie<br />
toirement ajouter pour que l'ensemble fonctionne.<br />
De plus, il est difficile d'étendre simplement le<br />
co<strong>de</strong> existant, même avec l'héritage : les classes<br />
Python conçues pour un produit <strong>de</strong>viennent la<br />
plupart du temps dépendantes <strong>de</strong>s autres éléments.<br />
Un autre problème vient <strong>de</strong> la conception<br />
<strong>de</strong> nouveaux types <strong>de</strong> documents avec les outils<br />
fournis par Zope. Le système n'est pas très<br />
souple et la plupart <strong>de</strong>s plates-formes disponibles<br />
pour Zope 2 ont développé leurs propres outils<br />
<strong>de</strong> <strong>de</strong>scriptions, à l'image <strong>de</strong> CPSSchemas pour<br />
CPS ou Archetypes pour Plone. Zope 3 apporte<br />
<strong>de</strong>s solutions <strong>de</strong> développement et <strong>de</strong> configuration<br />
plus souples et capitalise les évolutions et<br />
bonnes pratiques développées par les différents<br />
frameworks Zope 2.<br />
Caractéristiques <strong>de</strong> Zope 3<br />
Le développement <strong>de</strong> Zope 3, qui a démarré<br />
en 2001, est une réécriture complète du serveur<br />
qui conserve les bonnes idées comme le<br />
ZPT, la ZODB ou les concepts issus <strong>de</strong> CMF, et<br />
supprime les mauvaises. Zope 3 ne change pas<br />
les principes <strong>de</strong> Zope mais tente <strong>de</strong> fournir un<br />
outil plus flexible, plus près <strong>de</strong> l'esprit Python.<br />
Zope 3 est basé sur la Component Architecture,<br />
un framework orienté composants, à l'image<br />
<strong>de</strong> COM <strong>de</strong> Microsoft, KParts <strong>de</strong> KDE ou encore<br />
Corba, et comparable à ce qu'est l'OSGi pour<br />
Eclipse.<br />
Il est architecturé autour <strong>de</strong> 6 éléments<br />
majeurs:<br />
- Le ZCML et les interfaces<br />
- Les views et resources<br />
- Les utilities<br />
- Les adapters<br />
- Les factories<br />
Définition en ZCML <strong>de</strong>s vues <strong>de</strong> la FAQ.<br />
Le ZCML et les interfaces<br />
Sous Zope 3, chaque produit peut définir un certain<br />
nombre <strong>de</strong> fichiers XML pour se présenter<br />
au système. Ces fichiers XML sont exprimés en<br />
ZCML (Zope Configuration<br />
Markup Language), qui<br />
fournit un certain nombre<br />
<strong>de</strong> directives et qui est lu<br />
au démarrage <strong>de</strong> Zope. Le<br />
ZCML constitue l'épine dorsale<br />
du produit et en définit<br />
son architecture et ses<br />
caractéristiques.<br />
Les interfaces sont, quant<br />
à elles, une définition qui<br />
détermine un contrat fonctionnel<br />
que peut passer<br />
une classe. La classe<br />
FileRea<strong>de</strong>r peut, par<br />
exemple, respecter l'interface<br />
IFileRea<strong>de</strong>r, c'est à<br />
dire implémenter tous les<br />
éléments définis dans IFileRea<strong>de</strong>r. On dit dans<br />
ce cas que FileRea<strong>de</strong>r implémente IFileRea<strong>de</strong>r.<br />
Les interfaces sont omniprésentes dans Zope 3<br />
et la quasi totalité <strong>de</strong>s directives ZCML se base<br />
sur ces définitions plutôt que sur les classes<br />
qui les implémentent.<br />
Les views et resources<br />
Zope 3 fait une distinction encore plus nette que<br />
Zope 2 entre le co<strong>de</strong> <strong>de</strong>stiné à la présentation et<br />
celui <strong>de</strong>stiné à la persistance et à la logique<br />
applicative, facilitant ainsi l'application du<br />
modèle document-vue. Le co<strong>de</strong> d'affichage<br />
<strong>de</strong>vient une view et est invoqué par le système<br />
Programmez n°85 59 avril 2006<br />
qui lui <strong>de</strong>man<strong>de</strong> <strong>de</strong> prendre en charge l'affichage<br />
d'un objet publiable.<br />
Dans l'exemple <strong>de</strong> la FAQ, une classe FAQView<br />
est en charge <strong>de</strong> l'affichage <strong>de</strong>s objets FAQ,<br />
qui implémentent l'interface IFAQ, et une classe<br />
QuestionView pour la classe Question, implémentant<br />
IQuestion.<br />
Cette séparation nette facilite l'évolution <strong>de</strong><br />
chaque élément composant le produit, et permet<br />
aux développeurs <strong>de</strong> mieux organiser le co<strong>de</strong>.<br />
Les resources enfin, ren<strong>de</strong>nt disponible, toujours<br />
par une directive ZCML, un fichier ou un répertoire<br />
du système. Elles sont utilisées pour les<br />
images, fichiers CSS et autres éléments.<br />
Les utilities<br />
Les utilities définissent <strong>de</strong>s services globaux<br />
au système, et accessibles à tout co<strong>de</strong>. Une<br />
directive ZCML permet <strong>de</strong> déclarer une classe<br />
Python comme utility. Un exemple d'utility est<br />
le système <strong>de</strong> rapport d'erreur, qui peut être<br />
utilisé pour logger les erreurs rencontrées dans<br />
les différents produits.<br />
Les adapters<br />
Les adapters permettent <strong>de</strong> découpler une fonctionnalité<br />
particulière <strong>de</strong>s classes susceptibles<br />
<strong>de</strong> la fournir. Par exemple, une classe qui fournit<br />
un accès en lecture et écriture à un fichier<br />
peut, au lieu <strong>de</strong> l'implémenter elle-même, utiliser<br />
<strong>de</strong>ux adapters : un spécialisé dans la lecture<br />
et l'autre dans l'écriture. De cette manière, la<br />
lecture et l'écriture <strong>de</strong>viennent <strong>de</strong>s fonctionnalités<br />
indépendantes, pouvant s'appliquer à plusieurs<br />
types <strong>de</strong> classes. Cette technique permet<br />
aussi d'étendre les fonctionnalités d'une classe<br />
sans en changer le co<strong>de</strong> : un nouvel adapter est