Les installeurs Windows et MacOS X seront disponibles par la suite.
Pour ceux qui ne le savent pas, Plone est un CMS, une application permettant de gérer du contenu, en s'appuyant sur un véritable serveur d'application (Zope) et d'une surcouche à celui ci pour étendre ses capacités dans la gestion d'un site Web à fort contenu dynamique (CMF). C'est aspect lui confère un positionnement différent vis à vis d'autres CMS Open Source : le développement Web objet, qui simplifie grandement (sur le long terme) le développement avec la notion de "composants" réutilisables. Malgré la quantité importante de fonctionnalités, Plone reste malgré tout assez simple (comparativement bien sûr) à prendre en main pour un développeur. L'autre atout qu'apporte Zope est le langage ZPT, qui est un équilibre assez intéressant entre simplicité, puissance et respect des normes (entièrement xhtml). Enfin un travail énorme et de tout premier ordre dans l'interface utilisateur est fait depuis le début du projet : utilisation massive du CSS, réflexion sur l'accessibilité, utilisation du Javascript, l'interface se veut simple et utilisable.
Pour finir la présentation de Plone, ses principaux points forts sont aussi liés à la capacité de modifier tout ou partie d'un site pour l'adapter : workflows complètement paramétrables, création de types de contenu en un tour de main (ou surcharge de ceux existants), surcharge de n'importe quel élément de l'interface, développement de la logique avec un puissant langage (Python), tout en gardant une grande cohérence d'ensemble et sans devoir "forker" ou "patcher" Plone (ce qui serait un gros soucis avec beaucoup d'autres applications sur le long terme).
Les changements principaux sont :
- amélioration des performances
- utilisation de la branche 1.5 du CMF en lieu et place de la 1.4 (qui est obsolète)
- compatible Zope 2.8.x en plus de la branche 2.7.x
- un nouveau framework de gestion des types de contenu (Archetypes)
- nouveaux types de base (ATContentTypes) offrant de nouvelles fonctionnalités : référence entre contenu, capacité à définir sa vue par défaut ...
- nouveau type de base : les dossiers automatiques pour agréger du contenu
- amélioration des templates pour le respect des standards (XHTML, CSS, W3C AA, US section 508)
- nouveaux outils de gestion des CSS (CSSRegistry) et du Javascript (JSRegistry)
- nouvel éditeur graphique (Kupu) intégrant un tidy like
- syndication améliorée avec les dossiers, dossiers automatiques et résultat de recherches
- amélioration de l'interface utilisateur (mode plein écran, plus de métadonnées, configuration de la recherche, ajout d'un plan de site, ...)
- support du RTL (Right To Left) pour la gestion de certaines langues.
>
- Intégration de la couche Archetypes : développé depuis quelques temps (2 ans), le projet est devenu suffisamment mature pour être utilisé. Archetypes permet de créer très facilement des types de contenu. La philosophie est la suivante : un type est décrit dans un schéma, qui intègre une description des champs, les widgets ainsi que les fonctions associés (accesseurs, validateurs, ...). Ce qui permet à AT de créer automatiquement tout les écrans nécessaires (ajout, suppression, édition, ...) dynamiquement en lisant le schéma. Il est donc possible de créer un type personnalisé très rapidement. Bien sûr, ces écrans sont modifiables si ceux par défaut ne sont pas suffisants. Le développement de type suit dorénavant un paradigme objet. Autre avantage, la possibilité de "packager" des widgets, des validateurs, ... prêt à l'emploi.
- Types par défaut "Archetypisés" : l'intégration d'Archetypes a comme intérêt immédiat de transformer tous les types de base (qui étaient ceux de CMF) en types Archetypes (appelés ATContentTypes). Ajout d'un widget permettant de référencer un autre élément, thumbnail et redimensionnement pour les fichiers images, support ical/vcal pour les évènements... À n'en pas douter, les prochaines versions disposeront de nombreuses fonctionnalités supplémentaires. Il est donc très facile de les modifier.
- Utilisation du CMF 1.5 : la branche 1.4 n'étant plus maintenue, les core developers ont décidé de passer à la 1.5, enlevant du coup les monkey patchs dans Plone (CMF 1.5 ajoute des fonctionnalités supplémentaires comme la gestion des UIDs ou CMFSetup pour automatiser l'installation d'un site personnalisé).
- Support de Zope 2.8.x : sous ce titre peu évocateur se cache une nouveauté fondamentale. Zope 2.8 intègre le projet Five, une extension permettant aux développeurs d'accéder à une partie de la technologie Zope 3 (pour rappel, ré-écriture totale de Zope en partant d'une feuille blanche et de 7 ans d'expériences dans le développement d'un serveur d'application). L'intérêt pour cette technologie est immense car très prometteuse, et les différentes couches de Plone vont se développer pour converger avec Zope 3.
- Nouvel éditeur graphique Kupu : ce nouvel éditeur propose plusieurs avancées notables. D'abord la possibilité de disposer de plusieurs champs éditables avec l'éditeur pour un contenu. Ensuite, il dispose d'un mini (pour l'instant) tidy like permettant de nettoyer le code en indiquant les tags indésirables (whitelist & blacklist). Configuration des styles html pour les tables et des styles pour un champs d'un type (très utile pour normaliser le contenu html des types que l'on crées). Enfin, la gestion des UIDs pour ne pas casser les références quand on déplace les objets (la référence suit l'objet).
- Dossier automatique : un dossier automatique agrège le contenu d'un site selon les critères que l'on définit. Ces critères sont très nombreux (mais dépendant du type de contenu) et applicables sur les index (au nombre de 27). Un dossier automatique étant syndicable, on peut définir très précisément un flux RSS ! Enfin, il est possible de définir un sous-dossier (qui héritera des critères du pères par héritage) afin de spécialiser une agrégation.
- Vue multiple : il est possible de choisir pour chaque instance d'un type de donnée la vue que l'on veux (sur l'ensemble des vues disponibles pour ce type). Intérêt : plus besoin de créer un index.html pour une vue par défaut d'un dossier vu qu'on peut choisir le contenu, affichage en gallerie photo si le dossier contient des images, affichage par pile pour une suite de nouvelles ... (un nouveau produit en développement va permettre de choisir entre une dizaine de vues pour l'affichage d'un document). L'apport de cette fonctionnalité est une grande simplification dans le développement.
- Syndication : il est très simple de syndiquer un dossier ou un dossier automatique. Il est aussi possible de syndiquer une recherche, permettant de créer des flux RSS dynamiquement.
- Contrainte par type : on peut définir pour chaque objet conteneur les types autorisés.
- Blacklist des droits : un point fort de Plone est le paramétrage fin des droits car modifiable pour chaque object. Par défaut, une permission s'étend aux sous-objets. La version 2.1 ajoute la possibilité de désactiver l'héritage des droits.
- CSS & JS : deux utilitaires permettent de contrôler précisément la génération des CSS et du JS. On peut donner une priorité (afin de contrôler la surcharge), donner une expression (par ex. members.css n'est utilisé que pour les gens authentifiés), ajouter un CSS ou du JS sans toucher aux templates (très utile pour les développeurs d'extensions), et grande facilité pour charger/décharger un fichier précis. A noter un nouveau CSS pour les mobiles.
- Recherche dynamique (LiveSearch) : à l'instar d'un Google, on peut faire une recherche avec visualisation immédiate.
- Ajout de paramètres pour l'interface : possibilité d'indiquer les types visibles pour une recherche, dans le plan du site, l'arbre de navigation ou dans la porlet 'modifications récentes'. Message quand on quitte sans sauvegarder. Mode plein écran. Ajout d'un formulaire de contact pour un feedback à l'administrateur.
- Internationalisation : support du RTL pour lire de gauche à droite (comme l'hébreux) et amélioration du support pour l'extension LinguaPlone, qui permet de disposer de la localisation pour un document (document en plusieurs langues).
- Amélioration des performances : avec la ré-écriture de plusieurs parties (comme ExtendedPathIndex), la recherche, la création du plan du site ou de l'arbre de navigation ou le tri sont beaucoup plus rapides qu'avant.
Roadmap pour conclure :
Comme précisé dans le chapeau, Plone 2.1 est une base saine pour l'avenir. L'intégration d'Archetypes va permettre aux développeurs d'offrir un ensemble de composants : widget, validateur, type de contenu prêt à l'emploi. Le support de Zope 2.8 ouvre la voie vers une simplication de l'architecture générale avec l'emploi des interfaces, adaptateurs, vues et le langage ZCML de Zope 3. Parmis les changements attendus :
- utilisation massive de l'Ajax dans des composants prêt à l'emploi pour les développeurs
- refonte du système d'authentification (PlonePAS)
- intégration d'une application de gestion fine des membres (Membrane), modèlisant les membres. Ceci ouvre de nouvelles possibilités comme l'application de workflow sur les membres (par ex : approuver une inscription) ou la gestion des profils
- gestion des versions de contenu. Très utile par exemple quand on veut figer la version publiée mais laisser la possibilité de travailler dessus en parallèle
- intégration de l'extension multi langue afin de pourvoir créer du contenu en plusieurs langues
- refonte des portlets
- intégration de l'application Selenium pour créer des tests fonctionnels
Et bien d'autres choses encore ... Le futur de Plone est très excitant, et c'est tant mieux !
Aller plus loin
- Le site communautaire (3 clics)
- Téléchargement (3 clics)
- Nouveautés Plone 2.1 (3 clics)
- Proposition d'amélioration (PLIP) (1 clic)
# pourquoi une telle taille de police sur la roadmap????
Posté par cellier olivier . Évalué à 2.
La rodmap en devient illisible (taille 40 (au moins lol) et en rouge....)
sinon, c'est une info intéressante, je pars en lire (et en apprendre) plus ;-)))
[^] # Re: pourquoi une telle taille de police sur la roadmap????
Posté par BAud (site web personnel) . Évalué à 2.
bon dès que tu peux nous faire une synthèse des choses importantes, tu nous le dit hein (pas faute d'avoir essayé, mais ça fait mal au coeur de trancher dans le vif d'une dépêche si détaillée ;-) ).
# coquille
Posté par Aurélien Bompard (site web personnel) . Évalué à 3.
Il faut lire "de droite à gauche", j'imagine.
# Plone ...
Posté par Julien . Évalué à 3.
On nous oblige a utiliser ça au boulot et ... franchement je ne lui trouve que des défauts :
- basé sur Zope qui est lent, mal foutu, pleins de problèmes si on a le malheur d'utiliser une DB relationnelle, etc
- incomplet : le fait de devoir passer par la ZMI (...) est totalement absurde, menu d'administration est totalement incomplet. Je dirais encore si la ZMI était ce qu'on pourrait qualifier de "accueillante" ... mais c'est _loin_ d'être le cas, j'ai jamais vu un truc aussi laid et mal foutu ...
- templates bourrés de code incompréhensible (il n'y a cas voir le template utilisé pour générer le menu de navigation ...), à croire que les développeurs ne savent pas à quoi servent les templates ... (à éviter le code justemment ..)
- une tonne de modules qui ne sont plus développés, complètement buggés, qui plantent si on a le malheur d'utiliser la version 1.3.4 de la dépendance X et pas la version 1.3.3
- et puis c'est d'une lourdeur et d'une lenteur .... (merci Zope)
Personnellement je lui préfère de loin Drupal, même s'il est écrit en PHP ...
[^] # Re: Plone ...
Posté par Aurélien Bompard (site web personnel) . Évalué à 2.
Ouille ! Zope, mal foutu ?? Là ça fait mal. J'ai rarement vu un framework mieux foutu que Zope justement. Ca peut s'étendre dans tous les sens. Ca te fournit tous les éléments classiques du web tout en restant extrêmement souple.
J'ai pas bossé avec Plone, mais avec CPS qui est son "concurrent" et qui est basé sur le même framework, et j'ai trouvé ça sacrément puissant.
Par contre, évidemment, ça aime la RAM. Beaucoup même. Mais d'un autre côté, en changeant deux ligne dans un fichier de conf, tu passes à une architecture distribuée (load balancing + failover). C'est clair que pour faire la page de ma tante c'est pas la peine d'utiliser Zope. Mais pour faire quelquechose d'imposant et le garder contrôllable, je trouve justement que Zope est bien foutu.
[^] # Re: Plone ...
Posté par Sébastien Douche . Évalué à 1.
> foutu que Zope justement. Ca peut s'étendre dans tous les sens. Ca te fournit
> tous les éléments classiques du web tout en restant extrêmement souple.
Oula, tu dois parler de Zope 3 la non ? ;) Parce que l'API de Zope 2 commence à devenir un sacré bordel. Par contre, il est clair qu'il tient encore la dragé haute sur les fonctionnalités.
> J'ai pas bossé avec Plone, mais avec CPS qui est son "concurrent" et qui est
> basé sur le même framework, et j'ai trouvé ça sacrément puissant.
Oui, plus puissant que Plone d'ailleurs. La version 3 de CPS est d'ailleurs un point de repère pour la future couche CMS de Zope 3 (dont la société Nuxeo qui développe CPS est trés active).
> Par contre, évidemment, ça aime la RAM. Beaucoup même.
512 Mo de RAM et un proc à 1Ghz est recommandé pour être à l'aise.
> Mais d'un autre côté, en changeant deux ligne dans un fichier de conf, tu
> passes à une architecture distribuée (load balancing + failover).
Ca s'appelle ZEO, qui sépare backend et frontend. Ca permet de multiplier les frontaux. Plone.org par exemple en possède 2 (de mémoire) + 1 backend. Cela lui permet de tenir 30M de hits sans problème (c'est un site fortement collaboratif, ou tout est calculé dynamiquement).
> Mais pour faire quelquechose d'imposant et le garder contrôllable, je trouve
> justement que Zope est bien foutu.
Toutafé, le développement objet et l'utilisation de frameworks fait ici toute la différence.
[^] # Re: Plone ...
Posté par Nicolas (site web personnel) . Évalué à 1.
Qu'est-ce qui t'inciterait à choisir l'un plutôt que l'autre (et vice-et-versa!) ?
Merci d'avance.
[^] # Re: Plone ...
Posté par Sébastien Douche . Évalué à 4.
- Plone est un projet international, et issu de la communauté Zope. Il y a donc une "attirance" plus "naturelle" vers celui ci.
- CPS est un projet d'une entreprise française. Il est donc vu différent de Plone. De plus la communauté est principalement française a ce je sais.
Cela donc se ressent. il existe beaucoup plus d'hébergements Plone que CPS, plus de gens pour t'aider, plus de livres, plus d'infos, etc. J'ai l'impression (encore une fois, je connais assez mal le monde CPS, donc à prendre avec des pincettes) que Nuxeo n'a pas réussi à fédérer une communauté libre (ie hors clients) assez importante.
Techniquement, CPS est plus avancé et propose des fonctionnalités qui n'existent pas dans Plone. C'est clairement le CMS le plus abouti.
Donc j'aurai tendance à privilégier Plone, non pas techniquement mais pour le reste.
Pour l'avenir, et c'est un point trés positif, les différents créateurs des principaux CMS sous Zope (Plone, CPS, Silva) + Zope Corp ont décidés de s'associer pour développer l'équivalent du CMF pour Zope3 (en plus avancé evidemment). Donc même s'il existera plusieurs CMS, il existera un énorme tronc commun.
[^] # Re: Plone ...
Posté par Nicolas (site web personnel) . Évalué à 1.
J'aurai tendance aussi à choisir plus naturellement plone mais je n'ai pas complétement choix. Le choix s'est porté sur cps et il me faut de solides arguments pour ne pas choisir cps au profit de plone ou d'autre chose.
> Techniquement, CPS est plus avancé et propose des fonctionnalités qui n'existent pas dans Plone. C'est clairement le CMS le plus abouti.
Ca me rassure sur le choix qui a été fait.
[^] # Re: Plone ...
Posté par Sébastien Douche . Évalué à 2.
> - basé sur Zope qui est lent, mal foutu, pleins de problèmes si on a le malheur
> d'utiliser une DB relationnelle, etc
Lent ? C'est faux depuis au moins les versions 2.7.x avec l'utilisation de Python 2.2 minimum et la réécriture des parties critiques en C. Mal foutu ? Zope à débuter sa vie en 96, forcément ca date et il commence à faire son age c'est clair. Maintenant faut comprendre que Zope est un *serveur d'application*, avec tout ce que cela implique en fonctionnalité. C'est stupide de le comparer avec du PHP pur : il comprend une base objet qui gère la persistance, d'un broker objet et de la gestion de l'héritage dynamique.pour ne parler que de quelques spécificités phares. C'est pareil pour Jboss ou RoR. Et pour finir la dessus, le développement n'a plus lieu d'être en Zope 2 pur, Zope 3 arrive à grand pas.
> - incomplet : le fait de devoir passer par la ZMI (...) est totalement absurde,
> menu d'administration est totalement incomplet.
Effectivement, il y a encore besoin de passer de temps en temps par la ZMI mais cela devient rare, surtout avec la 2.1. Et cela concerne uniquement de l'administration avancée. De plus, l'utilisation d'extension qui vont bien diminue encore le recours à la ZMI.
> - templates bourrés de code incompréhensible (il n'y a cas voir le template
> utilisé pour générer le menu de navigation ...), à croire que les développeurs
> ne savent pas à quoi servent les templates ... (à éviter le code justemment ..)
Mouais, la on commence à voir les limites de tes connaissances sur le sujet. La portlet dont tu parles est dans skins/plone_portlet et fait 39 lignes. Le tout en xhtml valide :
http://svn.plone.org/view/plone/CMFPlone/branches/2.1/skins/plone_portlets/portlet_navigation.pt?rev=7921&view=markup
Le langage de template est le ZPT, qui manipule des tags HTML. C'est je trouve un des meilleurs systèmes de templating que j'ai pu voir : clair, propre et séparement clairement logique & présentation. J'aime ce compromis.
> - une tonne de modules qui ne sont plus développés, complètement buggés,
> qui plantent si on a le malheur d'utiliser la version 1.3.4 de la dépendance X
> et pas la version 1.3.3
Ce sont des développements externes. Et comme Plone utilise une succession de framework (Zope, CMF, Archetypes) forcément faut la bonne version. Tout les modules développés par des gens sérieux sont déja ou presique à jour pour la 2.1. Et la plupart commence même à développer pour Five/Zope 3. L'arrivée d'une surcouche pour création des types est aussi un bon en avant dans la normalisation du développement.
> Personnellement je lui préfère de loin Drupal, même s'il est écrit en PHP ...
Si cela te conviens, c'est tant mieux pour toi, tu as trouvé ce dont tu avais besoin. Mais dénigrer un produit que tu sembles pas comprendre, ni ce que tu peux en tirer est sans intérêt. Je reste trés intéressé par les autres CMS (Typo3 en particulier) et d'autres techno comme RoR et de ce que je peux en comprendre, c'est que Plone se défend trés bien (et ce n'est que la 5eme release). Surtout dans un perspective à moyen terme ou la technologie suivante est déja en route...
[^] # Re: Plone ...
Posté par Julien . Évalué à 1.
[^] # Re: Plone ...
Posté par Stéphane Klein (site web personnel) . Évalué à 3.
>On nous oblige a utiliser ça au boulot et ... franchement je ne lui trouve que des défauts
Pour te rassurer, j'ai entendu parler de Zope l'année 2000 environ. De cette date à fin 2004 j'ai "croisé" beaucoup d'articles au sujet de Zope : Zope Formular, Plone, ... Des articles dans GNU/Linux magazine et autre.
Pendant cette période, je n'accrochais pas du tout. Je me demandais "à quoi ça va me servir ?", "c'est vachement compliqué pour pas grand chose !", "je ne peux pas faire ce que je souhaite avec cette outil !"... Du coup, je continuais à utiliser le duo PHP/MYSQL pour les développements web tout en me rendant compte que je perdais beaucoup de temps sur divers points :
* j'avais souvent l'impression de recoder plus ou moins les mêmes choses
* il m'était (peut être par incompétence) difficile d'organiser correctement mon projet au niveau de la stucture du code source...
* difficulté à trouver un "modèle" de développement. Pourtant j'ai étudié (de loin) les méthodes de programmations de projets comme par exemple : dacode, phpbb, phpmyadmin... et d'autre. Sans jamais rien trouver de satisfaisant.
* aucune ou très peu de cohérence entre les applications PHP existantes. J'entend par là : difficulté d'intégration (HTML...), gestion des utilisateurs différentes...
Me rendant compte de toutes ces difficultées, j'ai cherché des solutions sur une période de 4 années environs. Je ne sais pas si c'est par incompétence, mais je n'ai rien trouvé de satisfaisant.
Après quoi, je me suis tourné vers Templeet. J'ai trouvé dans cet outil un certain nombre de fonctionnalités intéressantes. J'ai même participé à son développement pendant 6 mois (quelques patchs).
Au mois de novembre 2004, je surfais dans la documentation de mediawiki. Là, je ne sais plus trop où et comment, je suis tombé sur des discussions à propos des systèmes de templates : Smarty, template dans JSP,... Et je tombe sur ZPT. Je pousse un peu plus loin ma lecture et je comprends que ce langage de template est vraiment intéressant. De lien en lien, je continu à lire de la documentation/commentaire... au sujet de Zope.
Depuis ce jour, ça était la révélation. J'ai trouvé vraiment une plateforme propre, puissante avec une bonne communauté. J'ai acheté deux livres sur Zope :
* Eyrolles - Zope 2ème édition, que j'ai trouvé bon et utile
* Eyrolles - Zope/Plone 2ème édition. J'ai trouvé que ce livre est un bon point de départ pour Plone mais il reste assez simpliste. Il ne rentre pas beaucoup dans les détails. Il est accès plus "User" que "Developper".
Il est vrai que l'organisation de la documentation fait défaut pour un débutant. J'ai eu beaucoup de difficulté à trouver les informations. Elles sont à divers endrois assez disparates.
En conclusion : comme toi, pendant des années, je n'appréciais pas Zope. Jusqu'au jour où j'ai compris... maintenant je ne vois plus que par cela.
Maintenant, une question reste à élucider : pourquoi il est aussi difficile "d'entrer" dans la technologie Zope ? manque de communication ? mauvaise documentation ? sujet trop abstrait ?
[^] # Re: Plone ...
Posté par Julien . Évalué à 1.
Personnellement je préfère de loin le couple Postgresql / Python / Mod_Python / Clearsilver ... (évidemment il faut écrire des handlers ce qui est peut-être un peu plus compliqué...)
>Et je tombe sur ZPT. Je pousse un peu plus loin ma lecture et je >comprends que ce langage de template est vraiment intéressant.
Je suis désolé, mais quand je vois des choses comme :
<div metal:fill-slot="main" id="content-news"
tal:define="results python:container.portal_catalog(portal_type='News Item',sort_on='Date',sort_order='reverse',review_state='published');
results python:[r for r in results if r.getObject()];
Batch python:modules['Products.CMFPlone'].Batch;
b_start python:request.get('b_start',0);
portal_discussion nocall:here/portal_discussion;
isDiscussionAllowedFor nocall:portal_discussion/isDiscussionAllowedFor;
getDiscussionFor nocall:portal_discussion/getDiscussionFor;
home_url python: mtool.getHomeUrl;
localized_time python: modules['Products.CMFPlone.PloneUtilities'].localized_time;">
<form name="searchresults" action="" method="post" tal:condition="results"
tal:define="batch python:Batch(results, 15, int(b_start), orphan=1)">
(...)
c'est incompréhensible et ça n'a rien a faire dans un template ... (et je n'ai pas pris le pire exemple niveau illisibilité).
Alors peut-être que ça a été amélioré dans Plone 2.1, peut-être que les developpeurs de Plone n'utilise pas ZPT comme il faut, ... ?
>j'avais souvent l'impression de recoder plus ou moins les mêmes >choses
mouais ... pourquoi ne pas te faire une petite API personnelle, bien organisée en classes .. ?
J'avais aussi ce problème au début, mais par après je me suis fait des classes pour l'authentification des utilisateurs, des classes pour les menus, etc
>il m'était (peut être par incompétence) difficile d'organiser >correctement mon projet au niveau de la stucture du code >source...
ça ça vient avec la pratique :) Personnellement j'essaie d'implémenter un espèce de modèle MVC avec mod_python: un handler qui intercèpte les actions, qui dispatche vers un modules (souvent une classe par page), ces modules appellent mes classes de bases, et enfin me génère une structure HDF qui j'affiche avec Clearsilver. Ainsi tout est bien séparé (partie structure et logique), et j'ai des templates propres.
>Maintenant, une question reste à élucider : pourquoi il est aussi >difficile "d'entrer" dans la technologie Zope ? manque de >communication ? mauvaise documentation ? sujet trop abstrait ?
- Améliorer la ZMI serait déjà pas mal
- Réorganiser l'API qui est un vrai bordel
- Faire quelque chose pour améliorer la rapidité (apparement ya des progrès la dessus)
La première impression que j'ai eu avec Zope c'est que "c'est une grosse usine à gaz où il y règne un bordel assez conséquent"
voila ... ceci dit je n'ai _pas_ testé Zope > 2.6 ni Plone 2.1, donc ça c'est peut-être amélioré ça je ne dis pas :)
[^] # Re: Plone ...
Posté par Bertrand Mathieu . Évalué à 2.
pas loin en tout cas. Ça n'est pas un mystère dans la communauté plone que la template du portlet de navigation de plone 2.0.x est illisible, c'est même écrit en commentaire dans celle-ci!
> mouais ... pourquoi ne pas te faire une petite API personnelle, bien organisée en classes .. ?
Pourquoi le faire quand on dispose d'une API, pardon un framework, testé par toute une communauté? Pour le plaisir d'avoir des failles bien à soi?
> La première impression que j'ai eu avec Zope c'est que "c'est une grosse usine à gaz où il y règne un bordel assez conséquent"
Moi aussi au tout début j'ai trouvé ça un peu déroutant. Sur la courbe d'apprentissage le premier mois est carrément difficile, et il faut vraiment s'investir. Mais c'est un gros framework, il faut donc un temps conséquent pour l'appréhender; considérant ça ça n'a rien d'extraordinaire.
php/mysql c'est un langage et une base de données (comme python/mysql...), Zope c'est un serveur d'application. Ça fait une sacrée différence.
# Une tribune pour plone
Posté par didbaba . Évalué à 2.
Le seul hic, c'est qu'elle ne fonctionne qu'en 2.0.5 pour l'instant, laissez moi un peu de temps.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.