Zope, Zope3, ou Django

Honnetement, apres avoir experimenté Django et Zope, je suis parti sur
des libs persos et mod_python sous linux en mode 'psp'.

Tres rapide à mettre en place et tres performant. J'ai aussi essayé me
mode 'publisher', plus pythonesque, mais plus complexe pour moi a mettre
en place

si d'autres on des retours...

http://www.modpython.org/live/current/doc-html/pyapi-psp.html

Julien

Bonjour,

Je dois faire un choix d'architecture pour une nouvelle application.
J'essaye de comparer les avantages et les inconvénients entre Zope2,
Zope3, et Django.

Bin, ça dépend aussi de ton appli, et tu ne nous en dit pas grand chose...

Accessoirement, il y a aussi pylons (www.pylonshq.com).

Pas de problème pour Django, j'ai compris comment ça marche, j'arrive à
faire fonctionner un exemple d'application.
J'y arrive aussi avec Zope2, mais je n'ai pas compris l'intérêt. Y
a-t-il un avantage déterminant, et quel est-il ? Après une première
analyse, j'ai l'impression que c'est plutôt fait pour les gens qui ne
savent pas programmer, ou en tout cas qui ne maîtrisent pas la POO.

Heu... Alors tu a dû en rester aux exemples de base (template et scripts
via l'interface d'admin), ce qui ne couvre qu'une toute petite partie du
bousin.

Ceci étant, et même s'il y a des choses très intéressantes dans Zope2,
je ne recommenderais pas à quelqu'un qui ne connait pas déjà bien la
bête d'investir sur cette techno. C'est une usine à gaz, c'est *très*
mal documenté (ceci étant, s'il y avait une doc complète, tout le monde
fuirait en courant rien qu'en voyant le volume de la bête), et enfin
c'est en fin de vie.

Quant à Zope3, c'est encore pire. Je n'arrive à le faire fonctionner que
sous linux, en suivant pas à pas un tutoriel
(http://www.ibiblio.org/obp/pyBiblio/zope3/quickstart/) qui prends 10
pages pour afficher 'hello world' (oui, print 'hello world' en cgi...).

Aucun serveur d'application complexe n'est à son avantage sur un exemple
de ce genre. Ta comparaison est donc peu concluante.

Ceci étant, même s'il y a (certainement) des choses très intéressantes
dans Zope3, personnellement, j'ai décroché des usines à gaz !-)

Alors quant à savoir concrètement pourquoi c'est mieux que Zope2,

Plus propre, plus compréhensible (enfin, parait-il), et débarassé d'un
gros paquet d'antiquités qui posaient des pb de compatibilité avec les
dernières versions de Python.

et
pourquoi c'est mieux tout court, mystère !

Je ne sais pas ce que veux dire "mieux" sans précisions sur "que quoi"
et "sur quels aspects".

Si vous avez des idées sur la question, je suis preneur. Notez que j'ai
essayé google, mais je ne trouve que des opinions et pas des faits. Des
choses du genre 'à mon avis c'est bien mieux', plutôt que des arguments
bien concrets du style 'django a un langage de templates qui permet
l'héritage'.

Zope a un système de template qui permet aussi beaucoup de choses
intéressantes... au prix d'une verbosité assez fatiguante. Ca te va ?-)

Plus sérieusement, Zope2 et Zope3 sont d'une telle complexité qu'il est
difficile d'argumenter auprès de quelqu'un qui ne connait pas ces
systèmes - parce qu'il faut dans ce cas essayer de résumer en une ou
deux phrases des trucs qui peuvent prendre plusieurs semaines à
comprendre. Note que cette observation, à elle seule, en dit déjà
beaucoup...

En bref, oublie Zope2 de toutes façons, et si tu n'aimes pas les usines
à gaz bâties sur des fichiers de config XML par dizaines (Java ? Qui a
dit Java ?), oublie Zope3 aussi.

Par contre, Pylons est un projet très prometteur. Ce n'est pas encore
aussi poli et documenté que Django, mais c'est AMHA potentiellement
supérieur, dans le sens où d'une part ça se base autant que possible sur
des solutions 'standard' Python par défaut (WSG, paste, SQLAlchemy,
Genshi ou Mako, FormEncode, etc) au lieu de réinventer la roue, et
d'autre part où c'est pensé modulaire depuis le début (si tu n'aime pas
SQLAlchemy ou Mako, tu mets à peu près ce que tu veux à la place).

En ce qui me concerne, après avoir expérimenté (sur de vrais projets)
Zope2, Zope2+Plone, Django, et quelques trucs en PHP (pas toujours le
choix), et avoir fait mumuse avec Rails, je sais que si j'ai le choix de
l'outil pour un prochain projet 'from scratch', c'est Pylons sans la
moindre hésitation.

HTH

On 01-10-2007, Bruno Desthuilliers wrote:

Par contre, Pylons est un projet très prometteur. Ce n'est pas encore
aussi poli et documenté que Django, mais c'est AMHA potentiellement
supérieur, dans le sens où d'une part ça se base autant que possible
sur des solutions 'standard' Python par défaut (WSG, paste,
SQLAlchemy, Genshi ou Mako, FormEncode, etc) au lieu de réinventer la
roue, et d'autre part où c'est pensé modulaire depuis le début (si tu
n'aime pas SQLAlchemy ou Mako, tu mets à peu près ce que tu veux à la
place).

A propos, j'ai lu que Turbogears allait maintenant se baser sur Pylon (à
la place de CherryPy) et que donc chacun allait un peu plus se
spécialiser sur son niveau. J'ai enfin l'impression que le monde du
framework python est entrain de s'assainir, dans le sens où les
meilleurs composants commencent à sortir du lot et à être compatibles !

Est-ce que quelqu'un a essayé webob ?
http://pythonpaste.org/webob/
http://blog.ianbicking.org/2007/08/18/webob/


--
William Dodé - http://flibuste.net
Informaticien indépendant

On 01-10-2007, Bruno Desthuilliers wrote:

Par contre, Pylons est un projet très prometteur. Ce n'est pas encore
aussi poli et documenté que Django, mais c'est AMHA potentiellement
supérieur, dans le sens où d'une part ça se base autant que possible
sur des solutions 'standard' Python par défaut (WSG, paste,
SQLAlchemy, Genshi ou Mako, FormEncode, etc) au lieu de réinventer la
roue, et d'autre part où c'est pensé modulaire depuis le début (si tu
n'aime pas SQLAlchemy ou Mako, tu mets à peu près ce que tu veux à la
place).

A propos, j'ai lu que Turbogears allait maintenant se baser sur Pylon

Effectivement, c'est confirmé sur les deux groupes de discussions (TG et
Pylons).

(à
la place de CherryPy) et que donc chacun allait un peu plus se
spécialiser sur son niveau. J'ai enfin l'impression que le monde du
framework python est entrain de s'assainir, dans le sens où les
meilleurs composants commencent à sortir du lot et à être compatibles !

<aol />

Est-ce que quelqu'un a essayé webob ?

Connais pas.

http://pythonpaste.org/webob/
http://blog.ianbicking.org/2007/08/18/webob/

Uhuh... Ca m'a l'air pas mal aussi.

On 01-10-2007, Bruno Desthuilliers wrote:

On 01-10-2007, Bruno Desthuilliers wrote:

Par contre, Pylons est un projet très prometteur. Ce n'est pas encore
aussi poli et documenté que Django, mais c'est AMHA potentiellement
supérieur, dans le sens où d'une part ça se base autant que possible
sur des solutions 'standard' Python par défaut (WSG, paste,
SQLAlchemy, Genshi ou Mako, FormEncode, etc) au lieu de réinventer la
roue, et d'autre part où c'est pensé modulaire depuis le début (si tu
n'aime pas SQLAlchemy ou Mako, tu mets à peu près ce que tu veux à la
place).

A propos, j'ai lu que Turbogears allait maintenant se baser sur Pylon

Effectivement, c'est confirmé sur les deux groupes de discussions (TG et
Pylons).

Par contre je n'ais pas vraiment trouvé quels étaient les reproches
envers cherrypy. Mais je vois juste que la ml dev de ce dernier est
assez déserte...

(à
la place de CherryPy) et que donc chacun allait un peu plus se
spécialiser sur son niveau. J'ai enfin l'impression que le monde du
framework python est entrain de s'assainir, dans le sens où les
meilleurs composants commencent à sortir du lot et à être compatibles !

<aol />

Est-ce que quelqu'un a essayé webob ?

Connais pas.

http://pythonpaste.org/webob/
http://blog.ianbicking.org/2007/08/18/webob/

Uhuh... Ca m'a l'air pas mal aussi.

Oui oui, on s'oriente vers des librairies plutôt que des frameworks, ça
risque de tenir la route un peu plus longtemps !
A priori comme composants phares actuellement il y a
beaker pour les sessions
http://beaker.groovie.org/
(le meme qui fait routes)
http://routes.groovie.org/

authkit pour les autorisations
http://authkit.org/

flup (session) abandonne :
http://www.saddi.com/software/news/archives/58-flup-1.0-released.html

Par contre je ne vois pas trop l'intérêt de pylon par rapport
à assembler soit-même les composants ?



--
William Dodé - http://flibuste.net
Informaticien indépendant

On 01-10-2007, Bruno Desthuilliers wrote:
(snip)

Est-ce que quelqu'un a essayé webob ?
Connais pas.

http://pythonpaste.org/webob/
http://blog.ianbicking.org/2007/08/18/webob/
Uhuh... Ca m'a l'air pas mal aussi.

Oui oui, on s'oriente vers des librairies plutôt que des frameworks, ça
risque de tenir la route un peu plus longtemps !

Ou plus exactement: sur des frameworks basés sur des bibliothèques +/-
indépendantes...

A priori comme composants phares actuellement il y a
beaker pour les sessions
http://beaker.groovie.org/
(le meme qui fait routes)
http://routes.groovie.org/

authkit pour les autorisations
http://authkit.org/

flup (session) abandonne :
http://www.saddi.com/software/news/archives/58-flup-1.0-released.html

Par contre je ne vois pas trop l'intérêt de pylon par rapport
à assembler soit-même les composants ?

Moi si - après avoir écrit moi-même un petit framework WSGI !-)

pas que wsgi soit si compliqué, remarque. C'est juste que Pylons fourni
une (AMHA) très bonne infrastructure, une configuration par defaut à peu
près sensée et amplement modifiable, et tout ce qu'il faut pour déployer
aisément l'appli.

Ikaaro:
http://www.ikaaro.org/index/;view

Malgré le nom ce sont des français qui se cachent derrière ce en pur python.


--
Encolpe DEGOUTE
http://encolpe.degoute.free.fr/
Logiciels libres, hockey sur glace et autres activités cérébrales

Bonjour,
bonsoir

Je dois faire un choix d'architecture pour une nouvelle application.
J'essaye de comparer les avantages et les inconvénients entre Zope2,
Zope3, et Django.

Pour zope 3 une présentation en Francais
http://video.google.fr/videosearch?q=journ%C3%A9es+francophone+python
et sur grok aussi

Pas de problème pour Django, j'ai compris comment ça marche, j'arrive à
faire fonctionner un exemple d'application.
J'y arrive aussi avec Zope2, mais je n'ai pas compris l'intérêt. Y
a-t-il un avantage déterminant, et quel est-il ? Après une première
analyse, j'ai l'impression que c'est plutôt fait pour les gens qui ne
savent pas programmer, ou en tout cas qui ne maîtrisent pas la POO.

Un de ces avantages est de supporter des CMS ( pour moi CPS mais là j'ai
un point de vue d'exploitanpas dedev) et son ancienneté en fait une
pièce stable. L'architecture zeo assure une certaine scalabilité à
l'ensemble (théorique c'est quand même lent) .
En termes de dev je n'ai jamais eu le courage d'y rentrer et pourtant
c'est un produit Python....

Si vous avez des idées sur la question, je suis preneur. Notez que j'ai
essayé google, mais je ne trouve que des opinions et pas des faits. Des
choses du genre 'à mon avis c'est bien mieux', plutôt que des arguments
bien concrets du style 'django a un langage de templates qui permet
l'héritage'.

Je n'ai testé que tg ( une petite appli interne ... ). J'ai apprécié ses
widgets ( javascript python css le tout packagé) , ses raccourcis ajax,
son côté je fais un maximum pour vous qui permettent d'avoir un rendu
sympa pour des gens qui comme moi ne font pas du dev tous les jours.
La gestion du controleur m'a semblé un peu lourde à coté de produit
comme route, et ce framework a du mal à être stable sur le choix de ses
couches basses qui elles mêmes sont en cours de formation....Donc somme
toute normal....
L'adoption de pylons par tg est je pense , une bonne nouvelle , tg va
cultiver son côté standardisation et pylons permettra plus de fantaisie
et au dev plus confirmé d'être agressif technologiquement.

Je n'ai rien fait avec django mais l'adhésion au produit est forte
(nombre d'inscrits sur la liste google django est il me semble le double
de tg) et c'est un atout . Il ya des sites connexes comme django
snippets et le django book , c'est un plus certain. A mon sens c'est le
plus stable mais je le vois toujours en version 0.96....
Mais le tutoriel sur les sondages n'est pas très sexy à côte du wiki20
de tg.

Bref Le darwinisme est en train de frapper et je suppose que les choses
vont s'éclaircir, en tout cas pour le moment je ne batirais pas des
cathédrales sur ses produits mais une petite église de campagne oui.

Après même avis que mes camarades , pour le choix ca dépend de ce que tu
recherches.

Etant développeur web peu expérimenté tg m'a beaucoup apporté, ensuite
Pylons est très interessant ( son côté un peu artisanal me plait et je
vais l'essayer ).
Le support de SQLalchemy est intéressant dans le choix du framework.
SA supporte beaucoup de bases ( sauf db2 même si ibm semble s'interessé
au produit ). Django je crois devrait rebatir son ORM sur SA.
A suivre

Bruno Desthuilliers wrote:

Quant à Zope3, c'est encore pire. Je n'arrive à le faire fonctionner
que sous linux, en suivant pas à pas un tutoriel
(http://www.ibiblio.org/obp/pyBiblio/zope3/quickstart/) qui prends 10
pages pour afficher 'hello world' (oui, print 'hello world' en cgi...).

Aucun serveur d'application complexe n'est à son avantage sur un exemple
de ce genre. Ta comparaison est donc peu concluante.
Ceci étant, même s'il y a (certainement) des choses très intéressantes
dans Zope3, personnellement, j'ai décroché des usines à gaz !-)

Qu'est-ce que tu penses de la pérénité de Zope?

Bruno Desthuilliers wrote:

Quant à Zope3, c'est encore pire. Je n'arrive à le faire fonctionner
que sous linux, en suivant pas à pas un tutoriel
(http://www.ibiblio.org/obp/pyBiblio/zope3/quickstart/) qui prends 10
pages pour afficher 'hello world' (oui, print 'hello world' en cgi...).

Aucun serveur d'application complexe n'est à son avantage sur un
exemple de ce genre. Ta comparaison est donc peu concluante. Ceci
étant, même s'il y a (certainement) des choses très intéressantes dans
Zope3, personnellement, j'ai décroché des usines à gaz !-)

Qu'est-ce que tu penses de la pérénité de Zope?

Pour Zope2, il me semble clair qu'investir maintenant dans cette techno
serait une bourde. Je veux dire : pour quelqu'un qui ne connait pas du
tout la bête - personnellement, je continue à maintenir des trucs fait
avec, mais je ne développerai plus avec/pour.

Concernant Zope3, je ne suis même pas intéressé - je n'ai pas choisi
Python pour me farcir des fichiers de conf XML au kilomètre.