Sortie de MODx Revolution 2.0.0-beta-2

[lossendae]

La Team MODx vient de lancer la beta 2 de MODx Revolution

Pour la télécharger c'est ici

Il y a 2 versions:

- Traditional (beta-2.zip) - Pour les utilisateurs réguliers.

- Advanced (beta-2-advanced.zip) - Pour ceux qui désirent un plus petit téléchargement et une installation compressée.

Si vous ne disposez pas acces au root ou au sudo sur leur machine devrait utiliser la version traditional

Description:

- Manager mis à jour de ExtJS 2.2 à ExtJS 3.0 plus rapide et réactif

- Il est possible de glisser/déposer les "Elements" et "Resources" directement dans n'importe quel contenu (html).

Les tags MODx sont construit automatiquement.

- Rajout d'un retour visuel pour les "Elements".

Après les avoir glisser/déposer, vous pourrez sélectionner directement les propriétés désirées à partir d'un formulaire dédié.

Celui ci mettra en forme la syntaxe des tag MODx apres validation.

- Quick Update pour tous les Elements et Ressources. Plus besoin de quitter une page pour mettre à jour ou en créer une autre.

Vous avez directement acces au contenu et pouvez le mettre à jour directement.

- Basculez la disposition du Manager entre une présentation à onglets et une autre portail.

- Amélioration de la réactivité dans le Manager

- Fix: Probleme avec la désinstallation des packages; Ils se désinstallent correctement et crée une copie zippée des versions antérieures.

- Package Download section: Les packages que vous avez déjà téléchargés sont grisées.

- Gestion de tous les plugin assignés a un évènement (Event) à l'aide d'une grille (grid - tableau) intuitive.

- Nouvelle méthode pour la compression zip lors pour l'installation et le conditionnent (packaging) qui accélère le temps d'installation.

- Plein d'ajustement et de réparation de bug dans le framework.

Vous pouvez voir certaines des nouveautés dans ce screencast.

Note pour les mises à jour:

* Si vous mettez à jour à partie de Revolution 2.0.0-beta-1, vous devrez vider le cache de votre navigateur.

* Si vous rencontrez des problemes pendant la mise à jour, vous devrez probablement vider le répertoire core/cache.

* Pour les utilisateurs de Mac OSX qui mettent à jour à partir de versions alpha antérieures:

Quand vous remplacerez votre répertoire d'installation actuelles de Revolution avec la beta-2 (en local), pensez à faire une copie de sauvegarde du fichier core/config/config.inc.php,

Mac OSX lors de la copie de fichiers ne vérifie pas récursivement et pourrais effacer le fichier.

[davidm]

Merci pour l'annonce moi qui suis à donf dans OpenAtrium ces derniers jours je ne sais plus ou donner de la tête

En ligne de mire une RC pour la rentrée et d'ici fin septembre / début octobre une version finale

[vanquish]

Bonjour et merci pour l'info.

Je suis en train de refondre mon site et après 1 mois de tentative d'utilisation de Drupal + 8h de formation, je pense que je vais laisser tomber ce CMS/F qui me paraît beaucoup trop compliqué. Ok pas besoin de coder mais c'est pire puisqu'il faut totalement réapprendre une sorte de nouveau langage, nouvelles techniques, etc. Et quelle horreur ce système de template...

Puis il y a la conso de ressources... 250 requêtes par page, on marche sur la tête.

Je me permets donc de poser quelques questions :

- je me suis rendu sur le site de ModX espérant trouver un outil puissant comme Drupal mais simple comme bonjour et déjà ça commence mal, il y a 3 versions différentes ! 0.9.6, 1 et 2. Vaut il mieux utiliser la RC1 ou la Beta 2 ... ? En sachant que le site que je dois développer sera un site pro demandant une grande stabilité mais qu'il ne verra surement pas le jour en prod avant des mois

- est il possible de créer comme sur Drupal des "types de contenus" (par exemple : fiche technique auto ou recette de cuisine) ?

- existe t il sur ModX quelque chose d'aussi puissant que la taxonomie permettant de gérer tout le contenu sur de multiples critères ?

Le site que je souhaite refaire est un site de cuisine. Je pensais gagner du temps avec Drupal mais finalement, je pense en avoir perdu, et beaucoup...

Merci

Modifié 17 Juillet 2009 par vanquish

[lossendae]

Bonjour et merci pour l'info.

Je suis en train de refondre mon site et après 1 mois de tentative d'utilisation de Drupal + 8h de formation, je pense que je vais laisser tomber ce CMS/F qui me paraît beaucoup trop compliqué. Ok pas besoin de coder mais c'est pire puisqu'il faut totalement réapprendre une sorte de nouveau langage, nouvelles techniques, etc.

Je t'avouerai que je ne connais pas suffisamment Drupal pour être parfaitement objectif, mais que n'importe quel CMS t'impose certaines pratiques pour pouvoir les utiliser pleinement.

Même MODx, pourtant hyper flexible, dispose d'un language bien à lui qu'il faut connaître un minimum afin de pouvoir utiliser toutes ses possibilités.

Et quelle horreur ce système de template...

Je ne peux que plussoyer. C'est l'un des gros points positifs de MODx, même aujourd'hui je me demande encore comment les autres systemes arrive à mélanger html et php snas que ça gêne les dev (Wordpress je pense à toi)

Je me permets donc de poser quelques questions :

- je me suis rendu sur le site de ModX espérant trouver un outil puissant comme Drupal mais simple comme bonjour et déjà ça commence mal, il y a 3 versions différentes ! 0.9.6, 1 et 2. Vaut il mieux utiliser la RC1 ou la Beta 2 ... ? En sachant que le site que je dois développer sera un site pro demandant une grande stabilité mais qu'il ne verra surement pas le jour en prod avant des mois

Vaste débat. MODx sera scindé en 2 branche bien distinctes.

La 0.9.6 et le 1.0 représente la même branche -> MODx Evolution. Basé sur les eternelles bêta de MODx, largement utilisable en production et hérité d'Etomite.

La version 1.0 renomme certaines fonctions afin d'avoir un lexique plus proche de ce que proposera MODx Revolution.

Cette branche sera toujours maintenue par l'équipe officielle.

La branche 2.0 ou MODx Revolution, est une réécriture complète de MODx tout en gardant sa philosophie.

Certains site l'utilisent en production, mais je ne pense pas que ce soit forcement une bonne idée à ce stade de développement.

Tout dépend de ton niveau en php, de ton aisance en html et du temps de développement disponible pour ton projet.

A mon avis, la branche evolution est stable depuis longtemps et dispose de beaucoup de plugin interessant, et aussi plus d'aides disponibles sur le Forum officiel.

Davidm sera probablement de meilleur conseil que moi à ce sujet.

- est il possible de créer comme sur Drupal des "types de contenus" (par exemple : fiche technique auto ou recette de cuisine) ?

- existe t il sur ModX quelque chose d'aussi puissant que la taxonomie permettant de gérer tout le contenu sur de multiples critères ?

Sincèrement, malgré la difficulté que tu as à te conformer à Drupal et sa logique, je pense que c'est le CMS qui te permettra d'arriver plus rapidement à ton but pour le moment.

Essai de prendre contact avec nyl Auster sur ce Forum qui pourra te guider judicieusement vers des modules interessant et des astuces de codages "à la Drupal" pour faciliter ton développement.

MODx ne dispose pas encore de l'offre pléthorique de Drupal en terme de plugins dédié à une tache spécialisée (en témoigne le post de Davidm sur Openatrium)

Si l'outil est plus que prometteur, il reste en dessous de Drupal pour le moment.

[lossendae]

En ligne de mire une RC pour la rentrée et d'ici fin septembre / début octobre une version finale

Je pensais que la sortie de la version finale serais plus tard que ça!

Tres bonne nouvelle!

J'ai pas vraiment le temps de jouer avec pour le moment.

Les possibilités sont vraiment alléchantes, dès que j'ai plus de temps pour pouvoir m'y plonger, je vais tenter de porter de simple plugins d'autres CMS vers MODx Revolution.

Sans compter les expérimentations de Ryan pour un forum intégré qui devrais être relancées une fois cette période de gestation passées.

[nyl auster]

Je suis en train de refondre mon site et après 1 mois de tentative d'utilisation de Drupal + 8h de formation, je pense que je vais laisser tomber ce CMS/F qui me paraît beaucoup trop compliqué. Ok pas besoin de coder mais c'est pire puisqu'il faut totalement réapprendre une sorte de nouveau langage, nouvelles techniques, etc.

Tout dépend de tes besoins : dans mon cas le temps passé à apprendre Drupal me fait gagner aujourd'hui des journées entirères ou des semaines de développement. La courbe d'apprentissage est rude est on a souvent envie de laisser tomber en chemin mais si on a besoin d'un CMS puissant, flexible et qui peut prétendre faire à peu près tout type de site (communautaire, vitrine, boutique en ligne, intranet, annonces, blog, petit forum, multiblogging etc...) alors Drupal est une option à sérieusement envisager.

A noter aussi qu'il dispose d'un framework php très intéressant avec notamment une API pour les formulaires très rigoureuse et élégante qui permet de coder des formulaires très rapidement et sans avoir à marquer une seule goutte de html. Cette API des formulaires est pour moi un point crucial dans le choix de Drupal car ça veut dire que les formulaires circulent dans le CMS en tant que "tableau de tableaux" php jusqu'à l'affichage final.

Cela permet à un developpeur d'ajouter n'importe quel champ à n'importel quel formulaire de Drupal ou de masquer/préremplir n'importe quel champ de n'importe quel formulaire en passant par des fonctions spécifiques très simples à mettre en place.

Imaginons par exemple que tu veuilles ajouter sur le formulaire d'inscription du site un bouton radio avec deux choix "oui" et "non"; pour demander à l'utilisateur si il a bien lu les conditions générales d'utilisation du site : voici à quoi ça ressemble avec le framework de Drupal :

if($form_id == 'user_register'){
   $form['ma_checkbox'] = array(
	 '#title'	   => "Avez vous lu les conditions générales d'utilisation du site ?",
	 '#type'	   => 'radios',
	 '#required'  => TRUE,
	 '#options'   => array('oui', 'non');
  )
}
return $form

Ce côté "pate à modeler" m'a permis par exemple de développer en environ 5 ou 6 jours un systeme de multiblogging sur Drupal plus que pas mal.

Et comme l'a souligné lossendae, le nombre de modules et donc de fonctionnalités prêtes à l'emploi est pour l'heure nettement plus important pour Drupal que pour Modx.

Maintenant si Modx dispose de tout ce qu'il faut pour ton projet alors c'est évidemment un très bon choix et je préfère le fonctionnement de Modx à celui de Drupal, et bien sur niveau templating MOdx est un vrai bonheur. Il faut juste être conscient que la marge d'évolution possible de ton site via de nouveaux modules / snippets avec Modx est moins grande qu'avec Drupal.

- est il possible de créer comme sur Drupal des "types de contenus" (par exemple : fiche technique auto ou recette de cuisine) ?

Pour les types de contenus : oui et c'est même plus intuitif que Dans drupal et ses champs CCK : ce sont les variables de modèles de Modx qui sont intégrés au coeur de Modx. Ca permet de concevoir des formulaires sur mesure. Par contre à mon sens, bien que CCK soit plus lourdingue à mettre en place, galère à templater, il offre des possibilités plus vaste au niveau des types de champs et des actions qu'ils sont capable de générer.

- existe t il sur ModX quelque chose d'aussi puissant que la taxonomie permettant de gérer tout le contenu sur de multiples critères ?

Je nai pas testé la nouvelle version de Modx en profondeur mais sur Modx evolution, même si il est possible de bricoler soi même un systeme de tags graces aux variables de modèles, c'est incomparable à la taxonomie.

En revanche Modx permet d'organiser de façon très claire un site de façon hiérarchique et de générer automatiquement menu et fil d'arianne à partie de cette structure hiérarchique : Drupal est un cauchemar de ce côté parfois. Personnellement le seul véritable usage que je ferai de la taxonomie ce sont les tags à la volée; mais j'aimerai un autre systeme pour structure un site que la taxonomie qui reste pour moi une classification "transversale" alors que la plupart des sites sont clairement hiérarchiques / en rubriques.

Modifié 18 Juillet 2009 par nyl auster

[davidm]

OK Drupal n'est pas facile à apprendre mais c'est quand même faisable, mais comme tout système il faut mettre l'énergie pour apprendre, comprendre la logique et voir comment tout est relié. Ca m'a pris 1 mois pour avoir une bonne compréhension d'ensemble alors que pour modx c'était 15 jours donc oui c'est plus compliqué... Le problème essentiel de Drupal c'est la fragmentation extrême des composants que ce soit les modules ou les templates.

Aujourd'hui il y a une piste très prometteuse qui permettrait de compenser ça et faire franchir un cap majeur à Drupal c'est le trio : Spaces / Context / Features qui a permis à Development Seed de mettre OpenAtrium sur le marché en très peu de temps. Nul doute qu'on vera d'autres applis web créé avec ce combo. Perso ça va être mon focus n°1 côté Drupal car ça va permettre non seulement de systématiser le déploiement en évitant de se tapper les mêmes opérations d'installation, de config pour des profil de config similaires mais ça permettra aussi de mettre à dispo des fonctionnalités "packagées" et de donner la main au client sur l'activation la désactivation de fonctionnalités et certains éléments de présentation.

Bon mais revenons à MODx. Evolution 1.0 est parfaitement adapté à l'utilisation ne production et je suis d'accord avec nylauster, pour l'instant sauf si tu es un dév de haute volée qui a une bonne compréhension de revolution j'attendrai avant de me lancer avec en prod. Clarifions par contre une chose : Evolution est un produit plus abouti que la branche 0.9.x avec un nettoyage du code et une optimisation bien meilleure que la 0.9.x.

Maintenant pour moi l'avenir de MODx passe par Revolution, point barre. Evolution a été en avance sur son temps à une époque mais le marché actuel des CMS bouge extrêmement vite et un bon nombre de CMS qui ne changent pas leur approche vont être éliminé du jeu et d'après moi l'année prochaine va être pivot.

Si on regarde bien, cette année les champs custom sont devenus incontournables : modx, drupal, ezpublish ne sont plus seuls à les proposer mais Joomla a maintenant K2 et WordPress a Pods (et un autre plugin qui fait un peu la même chose, me rappelle plus du nom). Qui aujourd'hui peut se passer de cette fonctionnalité une fois qu'il l'a utilisé ? Personne à mon avis car c'est la base pour avoir une gestion de contenu structurée...

Mais ça ne va pas s'arrêter là. L'année prochaine on vera de l'abstraction de BDD avec des couche PDO sur mesure (xpdo pour modx, "DB NG" pour drupal 7) et une orientation objet qui prend toujours plus de place. La tendance déjà amorcée de gros travail ergonomique et d'interface comme celle effectué pour Drupal 7 avec D7UX (et Mark Boulton aux commande, un des meilleurs designers de la planète) ou encore le travail réalisé par la communauté pour MODx Revolution (pas encore aussi abouti mais en bonne voie) témoigne d'un nouveau seuil qualitatif.

Les interfaces vont être réellement orientées utilisateur, être plus légères, mieux optimisées. Il sera difficile aux CMS qui ne bougent pas de rester en compétition. De même les fonctionnalités d'administration type mise à jour "liveupdate" (MODx Revolution est meilleur que Drupal sur ce coup là avec le système de package et de MAJ depuis l'admin) ou traitement par lot et import/export de données vont faire la différence.

Dire que MODx est en dessous de Drupal n'a pas vraiment de sens selon moi. Je dirai plutôt qu'à l'heure actuelle il manque à MODx la couverture fonctionnelle apportée par les modules que Drupal peut offrir. Dans certains cas il vaudra mieux s'orienter vers l'un que vers l'autre. Mais le templating de MODx et son côté hyper flexible en font un système autrement plus rapide à déployer et plus léger à maintenir. Un de mes derniers site Drupal n'a pas moins de 140 modules (!!!) et vu qu'il n'y a pas de liveupdate avec la fréquence de mise à jour des modules c'est ultra galère à gérer. Sans compter ce que les Drupaliens appellent le clicodrome de config de ces mêmes modules. Il faut une mémoire d'éléphant pour bosser avec Drupal, parfois on se prend à se dire "mais quel module contrôle telle fonctionnalité ? Où est-ce que je configure ça déjà ou encore mais où est la permission associé à l'affichage de tel élément pour tel rôle ???". C'est assez usant...

Potentiellement MODx Revolution peut tout à fait égaler voire dépasser Drupal 7, sa conception étant totalement indépendante de plusieurs années de passé... l'enjeu majeur - encore une fois je ne cesse de le répéter à Ryan, Jason ou Jay - c'est d'attirer des développeurs vers Revolution pour que les addons fleurissent et que MODx franchisse le seuil critique qui fournira suffisamment de contributeurs pour avoir une dynamique constante de production de modules. Mais ce n'est pas gagné aussi génial un CMS soit-il, il n'est aussi fort que son maillon le plus faible...

[nyl auster]

Mais le templating de MODx et son côté hyper flexible en font un système autrement plus rapide à déployer et plus léger à maintenir.

ce qui me fait pencher vers drupal en ce moment aussi c'est la grande facilité pour créer des formulaires avec webform (cette facilité découle directement de l'excellente l'API des formulaires dont je parle ci-dessus), car un site sans formulaire de contact c'est rare et je supporte pas e-form. Et aussi la grande facilité à créer des formulaires en front-end pour que les utilisateurs contribuent au site. Parce que sur evolution c'était un peu traumatisant d'essayer de faire ça. (mais bon, tous les sites n'ont pas besoin de cette possibilité)

Modifié 18 Juillet 2009 par nyl auster

[davidm]

C'est vrai Webform est impressionnant, de la même manière probablement issue de l'API le très récent module NodeFormCols est une sorte de ManagerManager mais en plus facile à paramétrer... ça permet vraiment de modifier les formulaires d'édition des noeuds un gros plus en terme d'ergonomie.

Mais encore une fois, tout ça pourrait exister pour Revolution car d'après ce que je lis l'API va rendre tout ça beaucoup plus facile qu'avec Evolution... wait and see donc.

[nyl auster]

ouh mais ça a l'air d'être de la balle ton petit module drupal là :-)

Mais encore une fois, tout ça pourrait exister pour Revolution car d'après ce que je lis l'API va rendre tout ça beaucoup plus facile qu'avec Evolution... wait and see donc.

j'espère ! Le framework de Drupal m'a fait prendre conscience que de disposer d'une API de formulaire aussi flexible est un atout énorme pour un développeur. Je ne suis pas sur d'être pret à me réinvestir dans une API qui ne me propose pas cette flexibilité là ( non parce que apprendre une API c'est long hein :-/ )

En tous cas Modx Revolution a un potentiel absolument énorme, j'ai hate de trouver le temps de m'y pencher réellement.

Modifié 19 Juillet 2009 par nyl auster

[lossendae]

Je ne suis pas sur d'être pret à me réinvestir dans une API qui ne me propose pas cette flexibilité là ( non parce que apprendre une API c'est long hein :-/ )

Ton point de point de vue est tres compréhensible.

A mon avis, il faudrait une solution à mis chemin entre Drupal et MODx pour un generateur de formulaire.

Je ne pense pas que proposer une solution à la Drupal soit la solution:

1- ça existe déjà sur Drupal (et éprouvé).

2- L'utilisation de code php pour generer du html n'est pas vraiment dans la philosophie de MODx.

[nyl auster]

"2- L'utilisation de code php pour generer du html n'est pas vraiment dans la philosophie de MODx. "

Le truc c'est que l'api de drupal permet de développer très facilement des générateurs de formulaire très puissants. Cf module webform au hasard, comparé à e-form c'est un autre monde. Ce que je montre c'est juste la "mécanique" derrière les générateurs de formulaire ou le code que l'ont utilise pour créer des modules.

En fait je suis fénéant : je ne veux ni coder de php ni coder de html :-)

Or eform proposait à l'époque (ça a peut être évolué ave modx Revolution) une soupe entre html classique et balises modx que je trouve très rebutante.

[lossendae]

Je comprend oui.

L'idée serait au moins d'avoir le choix en cas de "flemme" de pouvoir générer facilement des formulaire de la manière la plus simple possible.

Et le moins que l'on puisse dire, c'est qu'effectivement Eform est loin d'être pratique et simple à utiliser comparé à d'autres outils plus récents.

Il me semble avoir lu quelque part sur le forum officiel qu'eform ne serait pas porté sur Revolution, ou en tous cas pas dans sa forme actuelle!

D'ailleurs, vous qui possedez beaucoup d'expérience avec divers CMS, pourriez faire une liste de 10 éléments/plugins qu'il manque à MODx pour se hisser au niveau de Drupal ou Joomla?

[nyl auster]

J'ai pas une grosse expérience des CMS mais les principaux points qui m'ont fait lacher Modx en faveur de drupal depuis quelques mois :

- gestion du multi-linguisme. Pas impossible dans Modx mais il faut faire rentrer un id dans une TV à un client, c'est pas envisageable pour moi. dans drupal, tu crée un article puis tu cliques sur "traduire" et zou.

- gestion aisé des formulaires en front-end : les sites sont de plus en plus souvent interactifs avec les internautes, proposant systeme de bog, de galerie d'images etc... Drupal est blindé de ce côté même si ça requiert pas mal de configuration.

- boutique en ligne : aucune solution maison pour Modx. Drupal dispose d'ubercart qui ne permet peut être pas de tout faire mais qui marche et qui est complètement intégré au reste du CMS.

- la grande facilité à créer ses propres modules sous drupal. Peut être parce que j'avais le livre qui va bien aussi...

[nyl auster]

Toujours personne qui a testé en profondeur modx revolution ? fait un petit site de test avec ?

[lossendae]

Je le test depuis 1 semaine et demi.

Côté php, j'ai eu du mal au début pour comprendre le fonctionnement de xPDO, mais une fois assimilé c'est vraiment indispensable. Je pense que mes développement même avec d'autres outils vont probablement être appuyé par xPDO en standalone.

Concernant MODx Revolution, le manager est pour le moment encore un peu confus.

L'organisation est totalement nouvelle et sans docs il n'est pas aisé de s'y retrouver facilement.

Je me suis amusé avec un thème lambda pour tester les tags, puis développé rapidement des prototypes de plugins utilisant les nouvelles méthodes d'appel pour les chunks, utilisation de xPDO. C'est vraiment plus facile. En revanche, le dispatchage des fichiers de snippets est plus compliqué. Au lieu d'être dans un seul endroit, il y a une partie dans le core et l'autre dans le dossier assets.

Il n'y a pas encore tous les modules intéressant, Ditto est présent en bêta et fonctionne bien avec les appels les plus simples, getResources aussi, mais par habitude je suis resté avec Ditto, Quip pour les commentaires est intéressant mais tres incomplets. Il me sert de base pour créer mes prototype actuellement.

Les autres éléments (Wayfinder, googlesitemap) fonctionne aussi exactement comme le faisait MODx.

La semaine prochaine j'expérimenterai avec la création de page de manager personnalisée avec ExtJs.

En revanche, pas de site en production avec, trop de bug assez gênant nécessitant de tout réinstallé. Je reste en local avec des données non importantes juste à des fins de test. Lors de la prochaine release, si le code est plus stable et que je dispose de certains snippets qui m'intéresse, alors je mettrais en place un blog dédié à MODx Revolution (et jQuery, et les CSS par la même occasion ).

Malheureusement, MODx Revolution va hériter de tout les avantages et inconvénient de son prédécesseur. Beaucoup de facilité, extremement modulable, mais tres peu de devellopeur talentueux pour lui fournir des extensions indispensables à son essor.

Et moi par exemple, je n'ai pas encore le niveau pour créer de véritable pont solide avec ce genre d'application.

Aujourd'hui j'ai vu les drafts du manager de D7, et c'est clairement impressionnant. En revanche l'abstraction de BDD sera moins puissante qu'xpdo.

Dans le même genre les shortags de Wordpress sont standardisés dans la dernière version et ressemble à de véritable appel de snippets.

J'ai presque peur que MODx s'essouffle avec le manque de support et finisse par ce faire rattraper.

Je ne penses pas avoir fait le tour de ce qui pourrai être intéressant à raconter, et vu l'heure, il n'est pas raisonnable de trop me triturer l'esprit. N'hésitez pas à me poser des questions plus précises sur les thèmes qui vous intéressent.

[nyl auster]

Merci pour ce premier retour.

"J'ai presque peur que MODx s'essouffle avec le manque de support et finisse par ce faire rattraper. "

Le tout est de voir avec quel facilité on peut créer des modules/ snippets intéressants et voir les mois passants si il y a contributions intéressantes. Je ne comprends toujours rien à XPDO (bon je me suis pas plongé dedans à fond mais pas trop le temps pour l'instant) : quel avantage cela apporte ? pourquoi l'abstraction de BDD de drupal est inférieure à xPDO ?

[lossendae]

Je reviendrais plus tard sur la création de snippets.

Concernant xPDO et le modele d'abstraction proposé par Drupal, je dois avouer que mon avis est peut être biaisé puisque je connais xPDO et je me base sur la doc de Drupal pour avancer des choses par forcément avec nuances.

Toutefois je vais prendre un exemple pour une simple insertion en BDD.

Avec Drupal:

$fields = array(
	   'nid' => 1, 
	   'title' => 'my title', 
	   'body' => 'my body'
   );

   db_insert('ma_table')->fields($fields)->execute();

Avec xPDO, 1ere méthode:

 $fields = $modx->newObject('ma_table');

   $fields->set('nid',1);
   $fields->set('title','my title');
   $fields->set('body','my body');
   $fields->save();

2eme méthode:

 $fields = $modx->newObject('ma_table');

   $data = array(
	   'nid' => 1, 
	   'title' => 'my title', 
	   'body' => 'my body'
   );
   $fields->fromArray($data);
   $fields->save();

Je trouve la première méthode d'xPDO plus claire, mais c'est totalement subjectif.

Je pense que les deux couche permettront d'effectuer les même tâches mais à l'heure actuelle celle de MODx me semble plus séduisante à l'utilisation.

Il est aussi à noter qu'xPDO fonctionne aussi avec php4, je ne sais si c'est le cas pour Drupal.

De plus que les commandes chaînées (comme la notation de l'exemple de Drupal $fonction->$chaine->$go) fonctionne aussi avec xPDO mais que la team recommande l'écriture objet "normale" afin de garder cette compatibilité descendante.

Modifié 3 Août 2009 par lossendae

[lossendae]

Je voualis tenter de répondre à la question concernant la création de document/snippet/chunks/modules mais j'ai pas vraiment le temps et de plus il y déjà une source assez complète à ce sujet et bien expliquée ici (en anglais)

Traduction et mise en forme dès que j'ai du temps devant moi, étant donné le fait que je ne suis pas très pédagogue

[nyl auster]

merci pour le lien. Ca a l'air très simple à prendre en main, ça me fait un peu rever là. Je surveille tout ça de très près. :-)

[davidm]

Petit exemple de addon développé pour Revolution en ce moment, Discuss, un forum natif MODx :

http://modxcms.com/assets/videos/forumdemo5.mov

Rock and Roll !

[lossendae]

Discuss est le nom officiel?

Il y a aussi Remark en préparation pour un système de commentaire plus simple mais néanmoins très complet (plus que Jot).

More to come!

[adn]

Sympa l'addon mais est-il vraiment comprehensible par un utilisateur lambda ??

Perso, j'ai testé la béta 2 sans succès. Ecran blanc à la fin de l'installation... En attente de la béta 3...

[davidm]

Tu parles du point de vue de l'utilisateur final ou de celui qui met en place ?

Parceque pour l'utilisateur final, c'est un forum comme un autre... pour celui qui met en place, ça ne sera pas plus difficile que pour MODx Evolution...

Pour l'écran blanc à la fin, c'est documenté et ce n'est pas un bug :

http://svn.modxcms.com/docs/display/revolu...escreen!%22

modx Revolution requière (pour le moment) que Memory Limit soit sur 64M mini, sur certains serveurs il faudra monter à 128M.

Ce reste en dessous de Drupal j'ai une install ou j'ai du passer à 256M

[adn]

Salut David,

Je parlais plutôt de l'utilisateur final. De manière générale, je trouve que les interfaces dynamiques ne sont pas toujours très faciles à appréhender.

Pour l'écran blanc, j'ai échangé sur le sujet, sans trouver de solution.

http://modxcms.com/forums/index.php/topic,.../topicseen.html

Mon memory_limit est à 128M, donc ce ne serait pas ce problème. Dommage car j'avais hâte de voir la bête