Cette nouvelle version apporte des innovations majeures dans le monde Zope/CMF (dépôt central de donnée, système de gestion de types de document en MVC, mécanismes de traduction, tout est workflow driven).
CPS3 notamment est en cours de déploiement par CCI.fr (Portail Internet, déployé), le CEA, le Ministère de la Culture (Intranet du Ministère), le Ministère de l'Intérieur (refonte des Intranets du Ministère), la Ville de Lyon (Portal Citoyen) ST Microelectronics (gestion de la documentation d'un projet important), et l'ADAE (projet DOLCE). Voici une description sommaire des modules qui composent CPS3 :
- CPSCore : fondations et services "core"
- PSDefault : implémentation par défault (skins, services, organisation)
- CPSSchemas : framework de gestion des formulaires (des champs, schémas de données, vocabulaires, etc) tant au niveau de l'affichage que du contrôle.
- CPSDocument : offre des fonctionnalités très avancées de création de types de documents en se concentrant sur la structure de données et sur l'interface utilisateur. CPSDocument permet de créer facilement des types de documents à travers la ZMI sans programmation.
- NuxMetaDirectories et NuxUserGroups : modules de gestion d'annuaires et de groupes d'utilisateurs. De plus, MetaDirectory permet de gérer tout type d'annuaire, pas seulement des annauires d'utilisateurs (structures, contacts, etc.)
Pour plus de détail sur chaque module, vous pouvez consulter l'annonce complète sur zope.org (voir lien ci-dessous).
Aller plus loin
- L'annonce complète (0 clic)
- CPS Project (2 clics)
- CPS chez Nuxeo (1 clic)
- Liste pour les développeurs (1 clic)
- Liste pour les utilisateurs (1 clic)
# Re: Première version packagée de CPS3
Posté par Fabimaru (site web personnel) . Évalué à 3.
[^] # Re: Première version packagée de CPS3
Posté par Ramso . Évalué à 2.
# Re: Première version packagée de CPS3
Posté par elamapi . Évalué à 3.
Je precise le fond de ma pensée:
Dans ma boite nous avons utilisée Zope pour le developpement d'application interne (serveur zope sous linux):
- Serveur de fichier.
- Gestionnaire de news.
- Gestionnaire de patchs.
- une ou deux autres applis.
Conclusion aprés 2 ans d'exploitation, a l'aideeeeeee !
C'est lent (n x plus que apache/php avec n>2).
Sur des applis un peu complexe, c'est infernal à maintenir (Mélange de produit python qu'il faut ecrire et déposer directement sur le serveur).
Les connecteurs de base de donnée sont TRES mal maintenu (au moins pour postgres) avec de liens à des librairies qui ne sont jamais utilisées en standard sous linux et difficiles à compiler voire plus maintenu du tout.
Le moteur de recherche fonctionne de manière aléatoire (essayez de faire un grep pour trouver tout les fichiers avec le mot "machin" .......).
Bref, nous avons remarqué que pour faire des sites qui n'utilisent que les produit par defaut de Zope et qui n'evolue pas trop, c'est effectivement pratique. pas plus.
[^] # Re: Première version packagée de CPS3
Posté par elamapi . Évalué à 3.
[^] # Re: Première version packagée de CPS3
Posté par elamapi . Évalué à 3.
http://www.zope.org.(...)
Regardez les produits, essayez de chercher de l'aide (language DTML, fonctionnement et configuration de Zope etc ...).
Puis faite la comparaison avec PHP sur php.net.
[^] # Re: Première version packagée de CPS3
Posté par Ramso . Évalué à 3.
* Documentation
o The Zope Book
o Developer Guide
o Administrator Guide
o API reference
o ZPT reference
o Using The CMF
o Zope Articles
o Zope How-Tos
o Books In Print
tout est là
(tiens, joli le copier-coller avec firebird)
[^] # Re: Première version packagée de CPS3
Posté par Fabimaru (site web personnel) . Évalué à 2.
[^] # Re: Première version packagée de CPS3
Posté par toto . Évalué à 2.
Apres une longue utilisation (effacement des objets...), est ce que t'as netoyé le zopefs ? (je suppose que oui)
je voudrai savoir quel est la taille de ton zopefs et si tu l'as splité.
merci
ps : j'ai un pote qui travail sur une appli dont le zopefs fait 5Go(ils remplissent le contenu du site). Et là c'est super lent.
[^] # Re: Première version packagée de CPS3
Posté par elamapi . Évalué à 1.
[^] # Re: Première version packagée de CPS3
Posté par philou (site web personnel) . Évalué à 2.
J'aime bien python en language d'extension de soft (script), facile, puissant, portable, complet, ..., mais est-ce python tiens la route en temps que language noyau ?
J'ai essayé gnue (un erp developpé en python) c'est hyper lent. J'ai comme l'impression que python, comme java sont des beaux languages qui demandent encore au moins 10 ans de progrès sur les micro-processeurs pour être agréable (en temps que language noyau).
Bref, est-ce qu'il existe un gros projet developpée en pur python en production ?
[^] # Re: Première version packagée de CPS3
Posté par elamapi . Évalué à 2.
Exemple (pour reprendre plus haut le cas de la ZoDB ou plus communément, le systeme de fichier Zope).
Zope n'accede pas par defaut au systeme de fichier de l'OS sur lequel il est installé. C'est bien dans un sens (sécurité sous windows car sous linux il suffit de faire tourner Zope sous un user avec des droits limité) et c'est SUPER mal de l'autre.
Pourquoi ? c'est simple, Le serveur fait deux fois le boulot chaque fois que Zope veux lire ou ecrire sur un fichier. La premiere c'est Zope lui meme qui le fait (en python) pour ecrite dans son systeme de fichier virtuel (la gestion de gros et nombreux fichier en python est particulierement lente) et la seconde, bein c'est l'OS lui meme pour effectivement faire les modifs sur le disque dur.
Je pense que sous nos OS (Linux pour ne pas le citer) les filesystem sont assez fiables et assez rapide pour devancer, en terme de performance, toutes implémentations virtuelles de filesystem.
Donc je n'ai jamais compris que les ZopeDevs n'ai jamais viré cette horreur de ZOPEFS.
[^] # Re: Première version packagée de CPS3
Posté par Fabimaru (site web personnel) . Évalué à 1.
Et bien, c'est la même chose avec Oracle non ? Il peut écrire directement sur le disque. Mais certains (je ne m'y connais pas trop) arguent que ce n'est pas la peine et tant pis si on a deux couches.
Donc je n'ai jamais compris que les ZopeDevs n'ai jamais viré cette horreur de ZOPEFS
Le jour où ReiserFS aura ses méta-data, ça sera peut-être le cas sous linux.
[^] # Re: Première version packagée de CPS3
Posté par elamapi . Évalué à -1.
Le python (semi-compilé, voire compilé à la volé ou semi-interprété) est leeeeent par rapport à des applis qui tapent directement dans les systeme (comme Oracle quand il n'utilise pas son propre file system).
En gros et pour faire symple, c'est comme si le justement cité ReiserFS, ou ext3 ou ext2 etc ... sous linux etait écrit en python, (et pourquoi pas un kernel linux en python interprété tant qu'on y est).
C'est pratique, on ne compile pas, mais c'est leeeeent.
Quand au méta data, pour 90% elle ne sont pas utilisé ou pas utile a l'utilisation du fichier concerné.
Exemple. Je crée un page HTML , je n'ai pas besoin d'avoir affiché en permanence le "titre" de la page (une des nombreuse méta data) etc ....
Quand à la gestion des utilisateurs, il y a les droits de l'OS (unix ou windows). Certe s, on a un peu moins de possibilité, mais c'est vraiment beaucoup plus rapide.
Puis, le petit détail vécu:
Sur la quantité de serveur que nous avons, nous avons déja eut des plantage de disque (Ext2,Ext3 et ReiserFS). Presque à chaque fois nous avons réussi à récupérer des données "a la main".
Par contre à chaques fois (5 fois en tout sur 2 ans) que le fs de Zope plante (le gros fichier devient éronné) , impossible de récupérer quoi que ce soit.
Je ne parle meme pas des backups du dit file system. soit on backup le fichier complet tout les jours (pas de backup differenciel/incremental possible) soit c'est a la main a coup d'export (super pratique avec 4 ou 5 sites en prod ......).
Bref, je persiste, pour de petit site a la maison, pour des sites statiques ou pour des CMS qui s'appuie sur une base de donnée ca peut le faire (et encore, avec une base de donnée on rajoute encore une couche).
Pour de la prod, personne ne m'a encore convaincu que je me trompais.
[^] # Re: Première version packagée de CPS3
Posté par Eric Barroca . Évalué à 6.
La ZODB n'est pas qu'une base de donnée ou un système de fichier. C'est, basiquement, un depôt d'objet qui offre principalement 2 services:
- Un mécanisme de persistance objet
- Un système de stockage
Le mécanisme de persistance permet de laisser le soin au système de gérer le stockage des objets. Cela évite ainsi au développeur de gérer pour chaque classe le stockage des objets (et donc, comme c'est le cas sans mécanisme de persistance de gérer à lamain le mapping objet <-> stockage physique).
Cette partie est d'ailleurs paramétrable via APE (Adaptable Persistance) qui permet de définir la façon dont on souhaite réellement stocker les objets : en tant que tel dans le dépot, sur le FS, sur le FS et dans le dépôt, dans le dépot et dans une base SQL, complètement dans une base SQL, etc. APE permet de définir complètement le mapping entre les objets et leur stockage.
Le système de stockage offre un mécanisme pour stocker physiquement le dépôt d'objet. Le mécanisme de base (FileStorage) stocke le dépôt dans un gros fichier ce qui a l'avantage d'être simple à mettre en place mais a la limite de la taille du fichier et des capacités de manipulation d'un gros fichier par l'OS.
Mais ce n'est pas grave. Il existe, en effet, de nombreux systèmes de stockage (ZODB Storage) qui permettent de stocker le dépôt de multiple façon : un fichier par objet dans une hiérarchie de répertoires (DirectoryStorage), une base Oracle (OracleStorage), une base BerkeleyDB (BSDDBStorage), distribué (sur un serveur de base Zope : ZEO), etc.
Une même instance de Zope peut d'ailleurs utiliser simultanément plusieurs stockages suivant les besoins (par exemple un DirectoryStorage pour les données et un BSDDBStorage pour les sessions).
Si l'on voit la couche ZODB comme une simple base de donnée, on peut considérer que c'est une mauvaise base, mais si l'on la considère comme un mécanisme de persistance, on constate que c'est un formidable mécanisme de persistance qui arrive au niveau de ce que l'on peut trouver dans le monde J2EE. Il ne faut pas se tromper d'utilisation. De même que si l'on utilise Zope pour simplement gérer des fichiers, je pense que ce n'est pas un bon choix. En revanche si on utilie Zope pour écrire des application web de gestion, travail collaboratif, gestion de contenu ou même traitement comptable, je pense que c'est un excellent choix.
Enfin, la partie de gestion physique (I/O) de la ZODB est écrite en C, pas en python. Donc ce qui manipule le gros fichier c'est du C :-)
EB.
[^] # Re: Première version packagée de CPS3
Posté par Encolpe DEGOUTE (site web personnel) . Évalué à 4.
La ZODB n'est pas un filesystem mais une base de données objets.
Il existe plusieurs solution de stockage, pas uniquement dans un gros fichier: Directory Stotrage, pour ne citer que lui, stock les objets directement sur le système de fichier et est optimisé pour ReiserFS.
Du coup pour la sauvegarde...
Pour les droits, la conception du modèle de gestion de droits dans Zope est beaucoup plus fine que celle d'un système de fichiers, donc elle a aussi un coup.
Pour la production, je dirai simplement que quelqu'un qui connait mal son outil de travail ne peut pas donner de jugement aussi catégorique.
[^] # Re: Première version packagée de CPS3
Posté par elamapi . Évalué à 3.
Les applications (gestionnaires de news et de patches) sont composées ainsi:
Interface WEB pour modifier/ajouter/suprimer des objets.
les objets sont des news ou des patches.
Les news sont en gros des chaines de caracteres internationalisées (c'est un des coté pratique de Zope) et sont dans la ZODB.
Les patches sont directement sur le FileSystem (EXT3), bien évidement on ne les stocke pas dans la ZODB (il y en a pour 15 Go).
Si Zope avait été choisi (pas par moi) à la base, c'est justement pour sa capacité à gérer les métas informations ainsi que sa gestions des droits qui semblait nous permettre de creer des architecture complexes de groupes et de sous groupes pour les accés au patches et news.
Les informations complémentaire des patches (association avec d'autres produits, contrats, tiquets, sont dans une base Postgres).
Arg premier drame, les connecteurs Postgres on mis longtemps à se stabiliser.
La mises à jours des connecteurs postgres ne suit pas l'évolution de postgres (C'est un peu la mort a recompiler - cf: mxdatetime).
Les fonctions de recherche fonctionne trés mal.
Exemple concret et vécu.
Nous avons le produit "A". Le produit "A" vient de changer de nom , il s'appele "B". Il faut donc retrouver tout les chaines de caractere (internationalisé avec des chaines zope sachant que nous n'avons pas poussé le vice à internationaliser à l'interieur même des chaines).
Ex:
CHAINE_A->francais="Notre produit A est super".
CHAINE_A->anglais="Our A product is wonderful".
ps: je suis mauvais en anglais.
Le but est de trouver toutes les chaines ou est marqué "A".
Ba j'ai jamais réussi, zope ne m'en trouve que peu ou pas du tout.
bref, la notion de grep (des fois c'est utile ...) je l'ai oublié avec zope.
Le DTML n'est pas forcement un exemple de clarté, de simplicité et de convivialité quand on programme.
etc ... etc ...
A oui!
Vous les expert, avec vos CVS. J'ai une question!
J'ai un site avec pas mal d'objet qui contienne du HTML pour les présentations, menu etc ..., tout est dans la ZODB. Je les récupére comment mes fichiers pour les poser dans CVS (sachant que l'on utilise déja un GROS cvs pour nos DEV (php,C,perl,docs)).
Ok Zope gere déja les versions. Alors dans ces cas la comment je fait mes backups ? export,sauvegarde de la ZODB, super pratique pour automatiser ca !!!!
Et pour les critique plus haut, on a 3 environements Zope.
1) dev
2) validation
3) prod
Bref, je persite, c'est clairement pas pratick pour la prod
[^] # Re: Première version packagée de CPS3
Posté par elamapi . Évalué à 2.
pour CMS et presentation , zope convient parfaitement
[^] # Re: Première version packagée de CPS3
Posté par Sébastien Munch . Évalué à 3.
C'est pour ça que ZPT a été inventé
Je les récupére comment mes fichiers pour les poser dans CVS
en FTP, en WebDAV... ou tu peux aussi faire ça en XML-RPC si tu veux...
Alors dans ces cas la comment je fait mes backups ?
tu sauvegarde le fichier Data.fs... et voilà, tout ton serveur est sauvegardé à un état donné.
[^] # Re: Première version packagée de CPS3
Posté par Eric Barroca . Évalué à 4.
Et vu les quelques sites importants, il est clair que ça tient la charge.
De plus Python est très utilisé dans l'industrie. c'est pas exemple language de script de CodeAster (un gros logiciel de calcul thermo-mécanique par EDF : http://www.codeaster.org(...)). Il me semble aussi que c'est utilisé par OpenCascade. Pour plus d'information la dessus tu peux consulter python.org.
Enfin, Python n'est pas fait pour être un language système à mon sens, mais un language de script de de prototypage. Dans Zope, par exemple les morceaux qui doivent aller très vite sont écrit en C et toute la partie interface et modules applicatifs en Python.
[^] # Re: Première version packagée de CPS3
Posté par elamapi . Évalué à 1.
Je pense que chaque langage a son propre domaine d'application.
Je n'ai pas encore vu J. Carman pondre un Quake like en Perl (qui pourtant existe sur toute les plateforme) et vice versa, je ne connait pas grand monde qui ecrirai un CGI en assembleur et de moins en moins de personne qui les écrive en C.
Je pense (j'en suis convaincu au vu des performance) que python n'etais pas le langage approprié pour Zope et sa gestion de ZODB.
[^] # Re: Première version packagée de CPS3
Posté par Ramso . Évalué à 3.
moi c'est de travailler sans persistance, sans langage dynamique et sans droits sur des permissions avancées qui m'horrifie :)
python n'etais pas le langage approprié pour Zope et sa gestion de ZODB.
python est tout à fait approprié pour travailler sur des applis web en tant que langage dynamique. sa syntaxe claire est un bonus.
implémenter la zodb en c ça se discute déjà plus
[^] # python...
Posté par Sébastien Munch . Évalué à 4.
Python n'est pas moin approprié qu'un autre langage...
C'est en tout cas le langage préféré des personnes qui ont écrit Zope... entre autres, Guido v. Rossum... le "papa" de Python.
Cela dit, recoder ce système en C ne serait pas un mal (et c'est (partiellement?) déjà fait).
L'avantage de Python, c'est sa facilité d'utilisation. Dans le cas de Zope (AMHA) :
- Zope est facile à coder
- Il est facile d'interfacer Zope (le "core") aux products qu'on y ajoute car c'est le même langage
Pour ce qui est des parties critiques, elles peuvent (et c'est le cas) être recodées en C.
D'ailleurs, dans tout projet, c'est une bonne approche : tout faire en Python, et passer les parties critiques en C. Tout faire en C dès le début est une perte de temps trop importante.
J. Carman
Carmack, s'il te plait...
[^] # Re: python...
Posté par elamapi . Évalué à 1.
Pour python, je ne dis pas qu'il est mauvais pour étendre les fonctionnalités de Zope.
Simplement je constate que La grande majorité de Zope est ecrite en python et la ca me parait injustifié.
[^] # Re: python...
Posté par Sébastien Munch . Évalué à 2.
Ensuite, les parties critiques ont été recodées en C. Mais il est inutile de tout recoder.
[^] # Re: python...
Posté par elamapi . Évalué à 0.
Exemple:
ecrite une page web (formulaire) avec un champ texte qui demande le nom et le prénom.
Puis un "CGI" (c'est pas un CGI mais j'ai plus le nom en tete).
Qui écrit "bonjour nom, prénom".
En PHP ca donnerai (pour la chaine bonjour) <? print "bonour $nom $prenom ?> sans rien de plus.
étendre le PHP par des lib, est aussi simple que include "machin.php" (machin pouvant etre sur une autre machine).
On fait ca comment en Zope avec python , simplement ...... ?
[^] # Re: python...
Posté par Sébastien Munch . Évalué à 2.
2) afficher ce que tu dis
- avec un script python :
'print "bonjour %s, %s" % (REQUEST.nom, REQUEST.prenom)'
MAIS un script python n'est pas fait pour rendre du HTML. Si tu veux faire ça en rendu HTML, tu utilise du DTML ou du ZPT, donc :
'<tal:block tal:replace="request/nom" /><tal:block tal:replace="request/prenom" />'
Effectivement, ce n'est pas plus court... mais ce n'est pas moins simple, et, à mon avis, c'est surtout plus logique.
[^] # Re: Première version packagée de CPS3
Posté par Fabimaru (site web personnel) . Évalué à 2.
Une instruction "native" (une fonction implémentée en C par exemple) peut relacher le "global lock" (par exemple s'il s'agit d'I/O), mais c'est une exception.
Bref, je ne vois pas comment obtenir des performances géniales si on a ce lock. En plus, d'après ce que j'ai compris on ne peut avoir qu'une instance de l'interpréteur par processus. Les tâches pouvant s'exécuter en parallèle ont ce fameux lock.
Si quelqu'un a mieux compris que moi, qu'il le fasse savoir, j'aimerais pas me présenter comme un auteur de FUD :-)
[^] # Re: Première version packagée de CPS3
Posté par Encolpe DEGOUTE (site web personnel) . Évalué à 4.
| - Serveur de fichier.
| - Gestionnaire de news.
| - Gestionnaire de patchs.
| - une ou deux autres applis.
|
| Conclusion aprés 2 ans d'exploitation, a l'aideeeeeee !
| C'est lent (n x plus que apache/php avec n>2).
Certes, mais c'est plus facilement maintenable.
| Sur des applis un peu complexe, c'est infernal à maintenir (Mélange de produit python qu'il faut ecrire et déposer directement sur le serveur).
Dans les cas de défauts de conception tout est complexe à maintenir.
Un 'produit' écrit en python est géré par un cvs/subversion en dev et seules les versions tagguées sont mises en production après une phase de test. Avec quelques scripts de migration ça se passe très bien.
| Les connecteurs de base de donnée sont TRES mal maintenu (au moins pour postgres) avec de liens à des librairies qui ne sont jamais utilisées en standard sous linux et difficiles à compiler voire plus maintenu du tout.
Ce n'est vrai que pour postgres car c'est le SGBD le moins utilisé en production.
Soit on utilise le SGBD objet de Zope (la Datafs), soit une annuaire LDAP en général.
| Le moteur de recherche fonctionne de manière aléatoire (essayez de faire un grep pour trouver tout les fichiers avec le mot "machin" .......).
Non, c'est juste un moteur anglosaxon, donc il ne prend rien en compte en dehors de l'ascii-us. Depuis un certain temps il existe TextIndexNG pour palier à ce problème.
| Bref, nous avons remarqué que pour faire des sites qui n'utilisent que les produit par defaut de Zope et qui n'evolue pas trop, c'est effectivement pratique. pas plus.
Comme toujours, cela dépend beaucoup de la conception originale des produits qui composent le sites. Si la conception est trop rigide, tout ajout demandera des contorsions pour contourner les problèmes de cette rigidité.
[^] # Re: Première version packagée de CPS3
Posté par Ramso . Évalué à 2.
Soit on utilise le SGBD objet de Zope (la Datafs), soit une annuaire LDAP en général.
t'es sûr de pas être tombé hors-sujet ? parler du back-end de mysql serait plus judicieux.
quand à celui de postgres, je crois qu'il y en avait 2 et qu'ils ont fusionné. ça va sûrement aider à le maintenir.
[^] # Re: Première version packagée de CPS3
Posté par elamapi . Évalué à 1.
Quand à les recompiler ... je vous laisse essayer
[^] # Re: Première version packagée de CPS3
Posté par elamapi . Évalué à 1.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.