| 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).
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 Encolpe DEGOUTE . En réponse à la dépêche Première version packagée de CPS3. É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é.