davidm

Annexe à ce fil mais MODx Evolution 1.0 est annoncé pour bientôt : http://modxcms.com/forums/index.php/topic,36505.0.html

Vu tes besoins beaucoup de CMS peuvent convenir car ils peuvent quasiment tous le faire... si tu veux un CMS avec un grand choix de thèmes tout fait tourne toi plutôt vers Joomla par exemple.

Merci pour le feedback Ca marche avec Chromium ? Pas testé... normalement Chrome n'est pas encore supporté pour le manager de Revo donc c'est une bonne nouvelle que ça marche avant même qu'ils se soient mis à bosser là dessus... Pour FireBug c'était déjà vrai avec la 0.9.x, et d'une manière générale à désactiver lorsqu'on bosse sous n'importe quel appli qui utilise pas mal de js... Pour la traduction je n'ai pas eu autant de temps que j'aurai voulu je ne suis pas sûr de pouvoir livrer demain, on verra... L'interface du manager est pas mal mais il y a encore de la marge au niveau ergonomique à mon avis. Le gros plus, c'est la structuration des ressources (TV, chunks, templates...) beaucoup mieux organisées qu'avant avec la nouvelle arborescence sur la gauche. Et le gestionnaire de fichier... enfin un gestionnaire rapide et qui fonctionne

J'ai pas eu un seul plantage de l'admin, mais je teste en local avec MAMP Pro 1.7.1... attention à bien virer FireBug et précision : Revo ne supporte pas encore Chrome par exemple donc quel navigateur plante ? Pour les properties pas encore d'exemple à fournir il va falloir que les dév nous alimentent un peu en tutos/exemples sur ce coup là pour voir comment ces propriétés sont utilisées...

Oui il y aura (en fait il y a) un script de migration (il a été utilisé pour modxcms.com d'ailleurs) mais qui ne doit pas être totalement prêt pour le moment, ce qui est compréhensible puisque tous les addons (notament Ditto) n'ont pas encore été mis au point sous Revo difficile d'avoir un script complet lorsqu'on a pas encore la "destination"... Maintenant on peut toujours demander sur les forums si le script peut être livré "tel quel" mais à mon avis ça supposerai un support énorme (tout le monde ne peut pas débugger soi-même) et ce ne serait pas forcémment pertinent...

Je n'avais pas répondu mais j'y serai personnellement ! 200 places sont parties, reste environt 600 mais il faut surveiller à mon avis...

Pour info je suis déjà sur la trad, j'espère avoir fini pour la fin de semaine / début de semaine prochaine Pour les droits le truc intéressant c'est qu'ils sont lié à la notion de "contexte", par défaut on a deux contexte dans Revo : web et manager mais on peut en créer autant qu'on veut (Un sous domaine peut être un contexte, une langue peut être un contexte et chaque contexte permet un override des paramètres). Ils sont aussi lié à la notion de "ressources" et de groupes de ressources (une resource est une page web, un lien symbolique, un lien...). On peut lié le droit d'accès à un groupe de ressource (là on retrouve la logique de la liaison groupe de documents <-> groupe d'utilisateur excepté que la notion de ressource est plus large que celle de document, notamment grâce aux liens symbolique vers des ressources situées sur les système de fichier). Ca permettra probablement d'avoir un niveau de flexibilité supplémentaire sur les droits. Sinon dernières nouvelles en direct de Twitter (si vous ne suivez pas #modx vous perdez pas mal d'infos en avant première...) : Ditto, un des snippets phare de la branche 0.9.x sera remplacé par une nouvelle façon de lister, trier et filtrer les contenus qui sera moins gourmande en ressource, plus simple et bien plus flexible (dixit Jay Gilmore cf ce post). Bonne nouvelle donc, car pour beaucoup d'entre nous migrer sous Revo sans Ditto = no go. Par contre il sera nécessaire de re-créer les listes créées avec Ditto sous 0.9.x...

Un des points disctinctif aussi, c'est la possibilité de "mapper" des ressources physiques (fichiers) avec des ressources web, autrement dit créer des liens entre le système de fichier et les documents modx... apparemment à part des système type "enterprise" (type Alfresco) c'est assez rare...

Effectivement même pas besoin de spécifier l'adresse, c'est vraiment puissant on a enfin dans MODx ce que propose Typolight ou CMS Made Simple c'est à dire un installeur directement depuis le manager mais aussi qui permet de gérer les updates. J'ai installé à peu près tous les packages, j'ai juste une erreur "modManagerLog: Attempt to set NOT NULL field item to NULL" qu'il va falloir éclaircir ! Il est peut-être un peu tôt pour le dire mais je dirai que c'est un évènement sur le marché des CMS... l'enjeu pour MODx c'est d'être capable d'attirer des dév pour développer rapidement des addons pour Revolution... je pense, personnellement, que Revo va rapidement prendre le pas sur la branche historique et que contrairement à ce qu'on aurait pu penser Revo est aussi un énorme progrès pour l'utilisateur final... l'admin n'est pas encore totalement "polie" mais déjà des années lumière devant ce qu'on avait... rien que le gestionnaire de fichier ! Pour info je suis en train de me mettre au travail pour la traduction française... juste à trouver mes marques dans les Lexicons et voire comment la création d'une langue se passe !

Oui : http://svn.modxcms.com/docs/display/revolu...evolution+Terms Revolution a déjà une doc bien plus complète que la 0.9.x et pour les développeurs / codeurs, cette documentation de l'API va vous changer la vie : http://docs.modxcms.com/

C'est officiel depuis 23h hier soir, MODx Revolution entre en phase de Beta ! Si vous aviez testé la version alpha, sachez que la beta dispose d'un manager largement amélioré et surtout d'une bien meilleur stabilité alors à vos test, partez ! Je vous rappelle l'url de la documentation (en anglais) : http://svn.modxcms.com/docs/display/revolu...MODx+Revolution, la page concernant l'installation est ici. Enfin pour les développeurs la documentation de l'API : http://docs.modxcms.com/ Si vous avez des soucis pour l'installation, vous pouvez poser vos questions ici ou mieux sur les forums FR. Il est probable que vous n'ayez pas l'extension PDO chargée sur votre config, j'avais écrit un petit billet à l'époque sur la procédure à suivre pour MAMP lorsque j'ai testé en local les premières alpha. Annonce originale : http://modxcms.com/forums/index.php/topic,....html#msg218697 Téléchargement : http://modxcms.com/download/ Attention il y a désormais trois distributions de MODx : Traditional (beta-1.zip) - Pour les utilisateurs finaux, archive extractible. Advanced (beta-1-advanced.zip) - Pour ceux qui veulent un package compressé, plus léger. Ceux qui n'ont pas d'accès root ou sudo utiliser la version traditionnal SDK (beta-1-sdk.zip) - Inclus les options de compilation du core, la doc de l'API, et les fichiers pour développeurs (bientôt dispo) La vaste majorité d'entre vous peuvent télécharger la traditionnal sans arrière pensée : la version "advanced" n'a pas de fonctionnalité supplémentaire, simplement elle est plus light.

Bien vu comment ai-je pu oublier l'e-commerce ? Donc tu classes Joomla dans les CMF (1.5 et > ou 1.x aussi ?). Par contre je trouve curieux de mettre en avant un framework tout en titrant "Joomla 1.5 API reference". Auparavant il était appelé "The Joomla! Framework API" (?!?). Ca donne envie d'y voir plus clair... J'ai fait un petit tour des définitions, et malheureusement l'anglais est bien plus précis que le français : Il y a pas mal de discussion sur le web à ce sujet... http://www.google.fr/search?q=API+vs+Framework Bon je pars dans des débats sémantiques mais c'est important de savoir de quoi on parle exactement... Ca se complique quand on regarde la définition d'un CMF : Je l'avais déjà citée d'ailleurs et je pense que c'est assez pertinent comme définition. Ca voudrait dire qu'un CMS qui peut être personnalisé via son API est un CMF. Techniquement, ça veut dire que j'aurai du classer Joomla dans les CMF Ca pose une question : dans quelle catégorie va t-on ranger les CMS qui sont bâti sur un Framework applicatif web (l'exemple d'Expression Engine 2.0 entièrement ré-écrit avec CodeIgniter vient à l'esprit) ? Potentiellement, cette nouvelle génération de CMS va avoir un potentiel énorme dans le sens où à partir du moment où un développeur maîtrise le framework, il peut facilement se mettre à développer des addons pour celui-ci. Il peut même coder par exemple une application métier avec ce même framework et l'intégrer facilement avec le CMS.

Ces typologies sont intéressantes pour s'y repérer mais un peu arbitraire car les frontières ne sont pas toujours aussi nettes... pour commencer je trouve qu'on applique le terme CMS à des applications web dont la vocation n'est pas forcémment la publication web et/ou la gestion de contenu mais c'est assez logique dans le sens où le contenu est une sorte de serpent de mer qui englobe tout et n'importe quoi. C'est un peu ce qui me conduit à penser que ce qu'on entend traditionnellement par CMS recouvre en réalité les systèmes de gestion de contenu "généralistes". Les applications web type Collabtive pour la gestion de projet collaborative ou Zimbra pour du Groupware, Compiere pour les ERP, VTiger pour le CRM ne sont pas des CMS pour moi. Je pense en plus que plus le temps va passer, plus les frameworks vont favoriser l'émergence d'applications web dans tous les domaines traditionnellement réservés aux applications "clients". Le développement d'Office Live ou de Google Docs montre que même la bureautique est concernée même si les usages vont mettre du temps à changer de ce côté là... le déploiement de techno comme la fibre, et de navigateurs plus performants (Chrome amorce le mouvement de navigateurs qui favorisent le dév d'appli en ligne) va certainement accélérer le mouvement en faveur d'applications hébergées sur des serveurs. Tout ça pour dire que les classements actuels qui concernent avant tout la publication et/ou le partage de contenus sur le web va s'étendre à d'autres domaines. Ceci étant dit, voici ma petite contribution avec une sélection de ceux sur lesquels je porterai mes efforts : Frameworks : Symfony, CakePHP, CodeIgniter, Django -> Pour développer des appli web sur mesure CMF : MODx, Drupal, Silverstripe, TYPOlight -> Pour mettre en oeuvre des projets nécessitant une forte personnalisation, évidemment des projets très jeunes comme TYPOlight ou Silverstripe et dans une moindre mesure MODx offrent moins de composants existants : il faut en tenir compte CMS : CMS Made Simple, Joomla -> Pour mettre en oeuvre rapidement des sites avec un niveau de personnalisation plus limité : soit le composant correspond exactement à ce qu'on souhaite = tout va bien mais quand on doit personnaliser, ça demande plus de boulot. CMS "Lite" : Concrete5, Zimplit -> Pour mettre en oeuvre des sites plaquettes, sans fonctionnalités complexe, avec une interface légère et facile à apprendre. Blog : Wordpress, Dotclear Wiki : DokuWiki, MediaWiki Collaboratif projet : Collabtive Groupware : Zimbra

Bon je reviens sur Revolution quelques screenshots : http://www.flickr.com/photos/36933895@N02/3502360592/

Ca n'est pas faux et c'est pourquoi j'insiste auprès de l'équipe sur le fait que l'effort de communication doit être plus important... je le répète je pense que l'effort de documentation et de communication auprès des développeurs dans un premier temps (pour que les addons se développent rapidement sous Revo), et auprès des designers dans un deuxième temps (quand on aura la "matière" pour proposer la doc + les addons suffisants pour avoir cette visiblité) va être critique. Il faut savoir que Jay Gilmore est désormais payé par CollabPad (la boîte de Ryan et Jason) pour marketer et communiquer autour de MODx, le projet ayant dégagé 35 000 dollars de financement pour 2009 cela a permis de booster le développement (quand on a un peu de cash pour voir venir, on peut développer au lieu de bosser sur des contrats, c'était le cas pour l'équipe de dév et c'est ce qui explique le tempo de dév) qui il est vrai n'a reposé que sur Jason pendant longtemps (d'où stagnation relative du projet). Avec l'arrivée de Shaun Mc Cormick puis le budget décroché par CollabPad, il y a eu une accélération (on va enfin entrer en beta) et j'espère que la comm' va suivre. A vrai dire j'ai moi-même moins de visibilité sur le projet car les orientations stratégiques ont un peu échappé aux membres historiques de l'équipe "communautaire" au profit de l'équipe collabpad. Il faut quand même bien comprendre que Revolution n'est tout simplement pas la même application (code radicalement différent), elle reprend l'esprit MODx avec des techniques à la pointe de ce qui se fait en matière de conception d'application web. Alors évidemment la transition ne va pas être automatique, ou du jour au lendemain mais ça peut aller très vite à mon avis si les dév / codeurs se mettent à produire des addons. Il faut savoir qu'il existe déjà un outil d'import automatique depuis la 0.9.x donc passer à Revolution ne devrait pas être si complexe. De toute évidence, comme en 2005 quand j'ai adopté MODx, seuls les pionniers vont tenter l'expérience dans un premier temps... et si tout va bien je prédis que l'essort de Revolution sera bien plus spectaculaire que celui de la 0.9.x. Je comprend l'attentisme et le fait que vous soyez dubitatif... à nous de prouver que l'équipe est en mesure de relever le défi (ce dont je suis convaincu) !

Effectivement je l'ai déjà mentionné ici et là, je pense que l'avenir appartient aux CMS développés sur la base d'un framework, de préférence largement répandu car alors la communauté de développeur qui maîtrise le framework est un facteur clé pour le développement de addons par la suite (et ou de possiblité de faire appel à un dév pour customiser le CMS en question). Expression Engine 2.0, ré-écrit sur la base de Code Igniter, sera une bonne jauge (même si EE est sous licence commerciale) d'ailleurs... C'est là qu'il y aura certainement un axe stratégique à développer par rapport à la promo d'xPDO. Ce qui est intéressant aussi c'est de voir que Drupal 7 s'appuierai sur sa propre version d'une couche d'abstraction aussi basée sur PDO (cf http://www.lullabot.com/drupal-voices/drup...-layer-drupal-7 et http://drupal.org/node/225450) Un des aspect qui affaibli le choix d'un framework pur, c'est que re-développer la couche CMS est : 1) Ré-inventer la roue 2) Pose le problème de la pérennité d'une application mono-développeur (ou pour un client, la dépendance vis à vis de l'entreprise qui développe le CMS) alors qu'une communauté et une licence libre est bien plus pérenne (à supposer que les développeurs quittent le bateau, le code est dispo et peut être repris par une nouvelle équipe). 3) Pose le problème de la maintenance et du bug-fixing : difficile d'égaler le modèle communautaire de ce côté là, du moins lorsqu'on a une communauté dynamique

Demande à Jason Coward, car je ne pourrai pas te redonner ses arguments (faut suivre un mec qui a un Q.I de génie) le résumé de Jason étant "xPDO was created after my horrible experiences with existing CRUD systems, including Propel and Doctrine", en français dans le texte il pense qu'on peut faire mieux et qu'en tout cas pour MODx, c'est plus léger et en adéquation avec les besoins (compatibilité PHP4 entre autre). Il y a pas mal de chose dans cette discussion aussi : http://echelog.matzon.dk/logs/browse/phpeclipse/1195513200 (Jason est "opengeek"). Certains ont l'air de penser qu'il n'a pas tort, notamment l'admin de phpfreaks : "There are many ORM systems available for php. Propel and Doctrine are probably the biggest, I've been using xPDO for a while because its so light weight (it doesn't build all the CRUD though)." (http://www.phpfreaks.com/forums/index.php?topic=185386.0). xPDO est utilisé en dehors de MODx donc, et s'appuie sur des méthodes affiliées à l'extreme programming, YAGNI. Encore une fois je ne suis pas développeur et il faudrait avoir un dév francophone qui maîtrise xPDO (par exemple Soda) pour expliquer un peu plus concrètement les choses. Drupal existe depuis beaucoup plus longtemps que MODx, on ne peut pas comparer. La cible n'est pas différente de celle de Drupal (sauf qu'il s'adresse plus au designers et tout autant aux développeurs), mais la logique de MODx elle, l'est ! Le but d'un CMF est de fournir la rapidité de customisation que proposer Symfony ou Zend sans avoir à construire la couche CMS qu'offre nativement Drupal ou MODx. Les débutants et utilisateurs finaux se sont toujours porté sur des CMS "en un clic", par contre pas mal de pros apprécient la flexibilité incroyable de MODx (et celle-ci va être démultipliée avec Revolution). Drupal est lui aussi flexible mais beaucoup moins que MODx. Je suis en train de travailler sur un projet (avec plusieurs experts internationaux) où nous allons proposer des tutoriaux comparatifs : comment mettre en oeuvre X ou Y fonctionnalité avec Drupal, MODx, Joomla... et alors pour ceux qui n'utilisent pas MODx ce sera une révélation. Pour certaines choses, là ou j'ai besoin de 20 modules avec Drupal, j'ai seulement besoin de 5 avec MODx et la flexiblité de combinaison entre eux me permet de faire la même chose en 5 fois moins de temps et avec un templating 10 fois plus rapide (et qui ne nécessite pas d'écrire des fonctions dans template.php ). Maintenant, aucun outil n'est pas parfait et chacun à ses forces et faiblesses... je bosse aussi avec Drupal mais comme le dit Nyl si MODx offrait autant de modules on passerai en un clin d'oeil à MODx sur tous les projets. C'est selon moi l'enjeu de Revolution, franchir le seuil critique qui permet aussi de faire des intranet avec MODx ou des sites communautaires complexes... Bon premièrement, pour mettre fin aux doutes, sachez que c'est officiel MODx Revolution rentre en beta ce mois-ci, et une RC est prévue pour la fin de l'été. L'automne 2009 vera Revolution 2.1 arriver avec le support de bases de données autres que MySQL. xPDO supporte PHP4 ça c'est certain. Evidemment que Revolution s'adresse à un public averti pour ce qui est du développement ou de la configuration... mais pas plus ni moins que Drupal. En même temps il y a un système de package installable directement depuis l'admin ce qui va simplifier les choses pour les addons, donc c'est un progrès. J'aimerai que tu m'expliques ce qui n'est pas propre ou qui ne suit pas une convention, parceque même en alpha, Révolution a une documentation de l'API qui n'a RIEN A VOIR avec la version 0.9.x : http://docs.modxcms.com/

Petite lecture complémentaire : http://fr.wikipedia.org/wiki/Mapping_objet-relationnel Plus complet, la version anglaise : http://en.wikipedia.org/wiki/Object-relational_mapping et http://en.wikipedia.org/wiki/Object-relational_database Concernant MVC, toujours sur Wikipedia : http://fr.wikipedia.org/wiki/Mod%C3%A8le-Vue-Contr%C3%B4leur Même si modx revolution n'utilise pas un schéma MVC "pur" de ce que j'ai compris (tout ça est très conceptuel...). En gros, modx Revolution devrait permettre facilement de créer (ou re-créer) des modèles de données en créant un modèle de données comportant des classes et des objets, et la couche ORM se charge du stockage, de la modification et d'une manière générale de la manipulation des données stockées (sans passer par du SQL, là on parle de CRUD : http://fr.wikipedia.org/wiki/CRUD). Un petit coup d'oeil au modèle de données xPDO de la 0.9.6 (télécharger le fichier schema_modx095_mysql.xml dans le premier post) peut aider à rendre les choses plus concrètes... http://modxcms.com/forums/index.php/topic,12895.0.html De toute évidence, tout ça est radicalement différent de la façon de raisonner qu'on a avec les systèmes actuels, c'est la grosse limite mais les portes qui seront ouvertes sont apparemment nombreuses...

modx revolution est réellement un "changement de paradigme", avec l'approche orientée objet combinée à l'abstraction de BDD. Ca m'a "amusé" de voir que Drupal 7, quelques mois plus tard, adopte une approche similaire avec une abstraction basée aussi sur PDO. Par contre si j'ai bien compris Drupal reste anti OO on reste dans le PHP procédural... xPDO est développé depuis près de deux ans, donc Revolution a de l'avance sur Drupal 7 à mon avis de ce côté là... wait and see ! La grande question reste : les développeurs / codeurs vont-ils adopter modx revolution ? Toute la réussite de cette nouvelle mouture, apparemment bien plus flexible et puissante côté développement, de l'adoption par la communauté des créateurs de addons... c'est pour ça que je tanne Ryan et Jason en disant que la com' et l'effort à destination des dév est clé dans la réussite de revolution et donc de modx...

Je rejoins ce que dit nyl dans l'ensemble mais une de tes exigences n'est pas *du tout* dans les clou avec Drupal : un système de template efficace et facile pour faire travailler un infographiste qui ne touche pas trop à la technique (il ne touche pas au php) Là il faudra passer son tour ou trouver un intégrateur en plus du graphiste (si celui-ci ne fait pas les deux) car avec Drupal, des choses qui prendront 5 secondes sous MODx vont prendre 15 minutes sous Drupal (et encore quand on sait déjà ce qu'on fait !). Exemple type hier je voulais juste ajouter une variable CCK à côté du titre dans le titre de la page, j'ai du chercher pour trouver un moyen de faire un override du template page.tpl.php qui est fonction du type de contenu (dans mon cas simplement une fiche ouvrage d'un éditeur, je voulais afficher l'éditeur à côté du titre). Déjà afficher une variable CCK en dehors de $content, ça demande un peu de php, qui n'est pas toujours très bien documenté (exemple : <?php print $node->field_editeur_editeur[0]['view'] ?> ) alors que dans MODx une simple balise [*nom-editeur*] dans le template ou dans un chunk et hop ! Si tu ajoute à ça la structure morcelée des templates dans Drupal, même si le système d'override est très puissant, il est lourd et on doit reconstruire une vue globale du template dans sa tête car contrairement à MODx on a pas de vision globale de ce qu'on fait... c'est donc une gymnastique et c'est le prix à payer pour disposer de ce qui fait par ailleurs la puissance de Drupal... Typolight est aussi une bonne plateforme de dév à mon avis (si tu aimes PHP OO, alors tu seras servi approche très différente de Drupal), mais il faudrait que tu discutes avec Cyril Ponce par exemple ou d'autres dév francophone sur typolight.fr parceque je ne peux pas te donner un avis suffisamment approfondi sur la question. Et il est plus flexible que Drupal pour le templating, il n'y a pas photo ! Le gros défaut de Typolight c'est la faiblesse de la communauté anglophone et un dév principal un peu autocrate (shut, j'ai rien dit...). Enfin pour conclure et ouvrir sur une autre piste et uniquement si ton projet n'est pas pressé, tu peux aussi attendre Expression Engine 2.0 qui est un CMS commercial par contre (mais pas très cher), dont le code est entièrement ré-écrit sous Code Igniter (le framework open source d'Ellis Lab, éditeur de EE). Petite preview ici : http://expressionengine.com/ee2_sneak_preview/ Je pense que les CMS construits sur la base d'un framework sont l'avenir du CMS, particulièrement si le framework sous jacent est adopté par un grand nombre de développeurs... ça veut dire potentiellement grand nombre de addons pourront être produits rapidement, avec une meilleure intégration aux core des CMS, une meilleure qualité globale de code et une meilleure sécurité...

C'est pas une question de chance, il ne faut pas hésiter à faire appel aux forums... j'ai eu des problèmes d'installation aussi, avant l'alpha4 mais depuis, plus de problème. C'est aussi une question d'environnement de test / de serveur, encore que les messages d'erreurs postés sont relatif à MAMP et je suis sous MAMP (Pro, il est vrai). Un certains nombres de bus sont documentés quand même et le guide d'installation est plutôt bien fait : http://svn.modxcms.com/docs/display/revolu...sh+Installation Les forums sont réactifs comme toujours donc on doit pouvoir installer Revo... qu'il y ai des bugs et soucis, c'est normal c'est une alpha !

Souci d'installation ? Hmmm, moi je n'ai plus eu aucun problème depuis l'alpha 4... ça dépend probablement de l'environnement serveur... Pour ce qui est de test plus approfondis ou de mise en oeuvre concrète dans le cadre d'un projet, non pas pour le moment en ce qui me concerne et je pense qu'il est un peu tôt (sauf exception, cf modxcms.com qui tourne sous Revo) pour déployer en prod. Je me réserve une bonne partie du mois de juillet pour vraiment me plonger dans Revolution, une fois ma mission actuelle sous Drupal terminée...

Le problème, plus que de coder soi-même, est surtout d'assurer la maintenance, les mises à jour de sécurité... un gros boulot pour un dév seul ! Rien ne vaut un produit communautaire de ce côté là !

non sauf si il y avait une refonte totale, ça ne risque pas d'arriver...

Dan a attiré l'attention des infogérés concernant cette alerte, et je me suis dit que ce serait bien de répercuter l'info pour ceux qui utilisent Joomla