MODx : SPIP Killer ?

[davidm]

Oui pour l'article Framasoft quand j'ai écrit que la courbe d'apprentissage était à la hauteur de la flexiblité et de la modularité de MODx, je ne voulais pas exactement parler de la même courbe d'apprentissage...

La difficulté dans MODx est plus dans la capacité à exploiter cette flexibilité à plusieurs degré (i.e à la fois dans la customisation de l'apparence que celle de la structure des informations...) que dans la compréhension du fonctionnement de l'application elle-même ce qui est plus le cas (en tout cas pour moi), de Drupal.

Je ne parle pas de créer un site avec Drupal, c'est facile. Là je parle de courbe d'apprentissage pour maîtriser (donc dans un contexte pro) l'application et en faire une utilisation avancée.

Pour les performances, elles sont au rendez-vous. Le cache fonctionne très bien. Pour la sécurité, je ne suis pas un expert donc j'attend le feedback !

En tout cas c'est sympa d'avoir un débat approfondi sur un CMS

[Loupilo]

Merci David pour tes précisions.

J'ai réussi à faire a peu près ce que je veux pour le menu, mais ça me laisse une bien mauvaise impression de devoir utiliser un script PHP... En tout cas pour l'instant, ça marche, c'est l'essentiel.

Par contre je n'ai pas trouvé l'endroit pour désactiver le bidule "QuickEdit" qui ne me sert à rien et défigure ma page et mon code... comment faire pour l'enlever ?

Merci,

Loupilo

[davidm]

La génération de menu dans Textpattern, c'est aussi du php... derrières les balises/tags tout est dans taghandlers.php

Sinon pour désactiver QuickEdit va dans Ressources > Gestion des Modules, là tu cliques sur QuickEdit et tu accède à l'édition du module où tu as une case "Le module est désactivé" (tiens, une erreur de traduction je vais remonter ça à Nicolas !!! ça devrait être "désactiver le module").

Et hop

[Loupilo]

Eh bien non, ce n'est pas pareil... Dans TextPattern, c'est (et c'est on ne peut plus logique) lui qui gère le PHP, moi j'utilise une syntaxe simplifiée que je peux appeller partout pour rendre ce que je veux.

Avec ce système, je dois éditer un fichier PHP en croisant les doigts pour qu'il fasse ce que je veux ?

Pour le menu, ça va encore, mais voila que je souhaite afficher les derniers articles dans une catégorie bien définie sur l'accueil.

NewsListing ?

Il n'est pas du tout mais alors vraiment pas du tout adapté à mes besoins (je dirai même à côté de la plaque, à partir du moment ou je veux personnaliser un minimum l'affichage de ces bribes d'articles).

Donc je suis obligé d'écrire un script PHP pour faire la chose la plus bête au monde ; afficher une courte prévisualisation des articles d'une rubrique ?!

C'est le rôle du CMS, pas le mien !

Voila une syntaxe normale :

<articles cat="1" limite="10" ordre="asc">
<h2><a href="[#URL]">[#titre]</a></h2>
<span class="date">[#date]</span>
<p class="previsu">[#texte couper="500"]</p>
</articles>

(pareil que page précédente, syntaxe inventée, mais c'est le principe de Spip, TextPattern, ...)

Ça, c'est bien un CMS... Il convertit lui même en PHP ce qu'il faut, et c'est évident !

Parce que si tu confirmes mes dires, je vais devoir réécrire le script (enfin si tu confirmes, je ne vais pas réécrire le script, j'abandonne ModX, je suis pas fou ) si je veux faire quelque chose d'un minimum correct (ce que me propose le script est bien trop classique ; je ne veux pas de "lire la suite" ni de "lire les commentaires", mais des icônes (img) encadrées dans un DIV avec une class bien définie, par exemple)...

Ce qui est marrant, c'est que question options c'est extrement complet, mais pour les choses les plus basiques possibles, on doit se compliquer la vie d'une manière incroyable !

Très bien qu'une télé puisse régler la luminosité de l'écran en fonction de la lumière ambiante et commander ta cafetière pour que quand ton film soit fini ton café soit prêt, mais si elle ne fait pas de recherche automatique de canaux et qu'on doit tous les entrer à la main... quid de la présence de fonctions avancées si elle ne comprend pas les ultra basiques ?

j'espère me planter sur toute la ligne en tout cas

Loupilo.

[edit: pour QuickEdit, le désactiver ne fait rien, j'ai été plus radical, je l'ai supprimé, là au moins il disparaît ]

[davidm]

OK bon je me suis mal expliqué...

J'ai recopié/mentionné le snippet PHP parceque l'aide n'est pas séparée du code contrairement à textpattern. Les explications sur les paramètres que l'on peut passer dans le DropMenu y sont incluses. Je vais suggérer qu'ils changent ça pour la prochaine version.

Mais tu appelles tout bêtement ton menu avec [[Dropmenu? tes_paramètres]]

La syntaxe des paramètres c'est &tonparametre='valeur_du_paramètre', en suivant les indications de la doc contenue dans le snippet.

Ca donne par exemple :

[[DropMenu? &menuName=`topMenu` &startDoc=`0` &levelLimit=`1` &topnavClass=`topMenubar` &here=`activeLink`]]

Voilà tout ce que tu as besoin d'insérer dans ton template

Pour QuickEdit, je vais vérifier qu'il n'y a pas de bug report et sinon je vais remonter ça... Merci !

[Loupilo]

David, bien sur, pour le menu, j'ai réussi à faire quelque chose qui me plaît car le script est effectivement exhaustif.

On peut choisir l'inclusion dans un DIV, les class des <li>, etc. très bien, c'est complet.

Mon problème, c'est pour aller plus loin, pour, par exemple, afficher une prévisualisation des articles d'une rubrique avec NewsListing.

Il rend un code très très loin de ce que je veux !

Donc je vais devoir modifier le script pour m'approcher un minimum du résultat que je veux !

Dommage que tous les snippets ne soient pas si bien finis que DropMenu.

Ce qui me gène c'est qu'on appelle le snippet sans choisir où il mettra les infos, il se débrouille seul à partir des paramètres qu'on lui donne... On ne contrôle que les options, pas la sortie (sauf pour DropMenu qui est très complet, c'est vrai) et c'est ça qui est très embêtant !

C'est à moi de définir la structure du code que renvoie NewsListing, pas lui

Loupilo

[davidm]

Ok je n'avais pas bien compris ce que tu voulais faire, autant pour moi...

Pour NewsListing je suis en train de jouer avec aussi... on peut modifier le code en sortie en utilisant le paramètre &tpl=`nom_du_chunk_qui_sert_de_template`

Exemple de chunk :

    <div class="summaryPost">
        <h3>[+title+]</h3>
        <p>[+summary+]</p>
        <div class="lien_fiche">[+link+]</div>        
    </div>

les variables ont été créé pour du blogging et je voulais utiliser des TVs (variable de template) mais c'est pas gagné... (voir http://modxcms.com/forums/index.php/topic,1531.0.html)

Ceci dit pendant que je suis là, il y avait une page dans la doc sur l'utilisation de DropMenu :

http://modxcms.com/snippet-dropmenu.html

[Loupilo]

Merci pour tes éclaircissements, mais... ton bout de code est utilisable ? Car si oui, c'est exactement ça dont je parle (et c'est une syntaxe de base qui devrait à l'évidence être intégrée par défaut ).

Et je vais jeter un coup d'oeil sur la doc de DropMenu

Merci,

Loupilo.

[davidm]

Oui on peut utiliser ce qu'on veut... disons que les nbsp et le code de départ ne me convenait pas donc j'ai changé en fonction de mon cas précis...

Sinon grande nouvelle après plusieurs heures de boulot avec Susan Ottwell je suis en mesure d'annoncer la mise en ligne d'une version de MODx qui tient compte des restrictions imposées par les pages perso de Free

Encore une preuve si besoin était de la vitesse et de la compétence de l'équipe de dév de MODx !

voir [Epinglé] Version spéciale Free de MODx + Demo en ligne

Lien de téléchargement :

Version de MODx "Special Free"

Démo en ligne sur mon hébergement Free

Login: demo

Mot de passe : demo123

Notez que pour des raisons de sécurité, j'ai donné à l'utilisateur démo la plupart des droits administrateurs, mais pas tous. Ceci devrait vous donner une idée malgré tout. Sachant que le but de cette démo n'est pas de tester MODx mais de constater que cela marche sur Free

[Loupilo]

David, où se situe l'appel au snippet NewsListing dans le code que tu as donné ?

Une fois de plus je n'ai peut-être rien compris et l'exemple de code que tu donnes ne se met peut-être pas dans les gabarits

Merci de tes infos

Loupilo.

[Edit: en tout cas, juste pour voir, j'ai mis [[NewsListing? &startID=2]] dans mon gabarit, et j'ai une erreur MySQL ]

[davidm]

Non le code que j'ai donné est situé dans le code du snippet lui-même...

Pour ton erreur probablement parceque tu as utilisé ' au lieu de ` , chez moi ça marche nickel...

Essaye donc [[NewsListing? &startID=`2`]]

Sachant que normalement, si tu laisse les options par défaut ton menu démarre à partir de l'ID du doc où tu te trouves

[Loupilo]

Ah oui pas bête David... reste plus qu'à trouver ce caractère sur mon clavier

Bon, je n'ai plus d'erreur MySQL...

...juste ça :

Fatal error: Cannot use [] for reading in /var/www/manager/includes/document.parser.class.inc.php(770) : regexp code on line 1

Je vais aller voir sur les forums officiels si ce n'est pas un problème connu...

Merci pour ton aide et ta patience, en tous cas

Loupilo.

[davidm]

De rien

Ceci de mémoire je me demande si ce n'est pas une question d'espace avant la fin du menu ]] (tu ne dois pas en avoir avant ]] )

ce n'est pas ça ?

[Loupilo]

Non ce n'était pas ça, il n'y avait déjà pas d'espace

J'ai trouvé quelques messages sur le forum, quelqu'un a trouvé une solution (que je n'ai pas réussi à traduire...), et finalement une autre a été donnée : mettre à jour NewsListing vers la 1.1.

Et effectivement, tout fonctionne !

[Edit: par contre dès que j'ajoute ton code à la fin du snippet, j'ai une erreur : Parse error: parse error, unexpected $ in /var/www/manager/includes/document.parser.class.inc.php(667) : eval()'d code on line 860 ]

[davidm]

OK pardon en fait j'ai hacké le Snippet alors que ce n'est pas nécessaire... J'ai modifié mon message initial ci-dessus (#32) avec les bonnes instructions

Il n'était pas utile de hacker le code, le Snippet est bien conçu il vérifie que si le paramètre &tpl est renseigné, alors il va chercher le chunk qui sert alors de template pour la visualisation du summary

Exemple ci-dessus (#32)

Puisque je suis là, j'en profite pour annoncer que je suis officiellement passé dans la Marketing & Design Team de MODx

[Loupilo]

Effectivement, ça marche, mais ma structure étant construite de cette façon :

Index
-/Blog
--/Catégorie 1
---Billet 1 catégorie 1
---Billet 2 catégorie 1
--/Catégorie 2
---Billet 1 catégorie 2
---Billet 2 catégorie 2
---Billet 3 catégorie 2

J'ai bien l'impression qu'il ne veut pas fouiller plus loin que la premier niveau (il m'affiche le nom de mes dossiers Catégorie x, aucun de mes billets).

Je vais essayer de jouer sur les options...

En tout cas félicitations pour ta "promotion". Concrètement, ça veut dire que tu vas faire quel boulot ?

[davidm]

On est maintenant 3 à s'occuper du Marketing et 2 des aspects Design (notamment j'ai maintenant pu voir la future interface de MODx... yeah ).

Ca veut dire principalement s'occuper de promouvoir MODx/Tattoo : définir les cibles, le positionnement par rapport aux autres CMS, les actions à mener pour faire connaître MODx, la définition des besoins utilisateurs pour déterminer les axes de développement à venir...etc. Ca c'est pour la réflexion. Côté concret mon rôle est de suivre ce qui se dit sur le web (veille), intervenir dans les forums spécialisés, obtenir des publications (comme l'article de Framasoft ), etc... En plus de ça, j'ai voie au chapitre sur les aspects de design qui sont géré par des designers et graphistes.

J'ai aussi accès aux infos sur les orientations techniques à venir (et je participerai aux discussions même si je ne suis pas codeur...) et accès à SVN Sinon je continuerai à aider à maintenir la VF et tout ce qui va avec les aspects de traduction.

Pour le snippet NewsListing, je n'ai pas encore regardé si tu peux effectuer un listage de ce type. Cela m'étonnerait que ce ne soit pas prévu. Mais il faut que je creuse un peu plus...

A savoir plusieurs versions modifiées ont été publiées, notamment Susan a publié un NewsListingPlus :

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

et http://modxcms.com/forums/index.php/topic,1565.0.html ajout de longtitle)

et enfin http://modxcms.com/forums/index.php/topic,1432.0.html (date de publication au lieu de date de création)

Toujours aussi rapide, ces différentes modifs ont été intégrée dans une version 1.2

Voir cette page :

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

Voilà !

[Loupilo]

Merci pour ces liens je vais aller voir tout ça

Sinon pour que ModX se répande, faut qu'il soit plus simple sur sa syntaxe (enfin actuellement il n'y en a ça simplifie le problème ).

Je veux dire que le principe des "snippets" qui gèrent l'affichage du contenu c'est un délire (je trouve personnellement que c'est n'importe quoi).

Ils devraient s'inspirer de TextPattern : pour obtenir ce qu'il veut, l'utilisateur utilise la syntaxe dispo (ici les <txp>) et peut tout faire avec, il n'a pas pas à appeler des bouts de codes qui choisissent le code HTML qu'ils rendent, ni prier pour qu'un snippet qui fasse ce qu'il veut existe...

L'utilisateur doit avoir le contrôle dans les modèles de pages et là... ben force est de constater qu'il ne l'a malheureusement pas !

Il doit pouvoir choisir si il veut faire une liste de rubriques, une liste d'articles dans une rubrique, enfin bref il doit pouvoir controller de A à Z où s'affiche ce qu'il veut qui s'affiche !

Et le paradoxe c'est que ModX est incroyablement complet (et c'est bluffant...), que les options d'affichage sont très très complètes (on peut choisir un gabarit par page, si on veut que telle page soit dans le menu, ...), mais qu'en parallèle on ne puisse pas contrôler le contenu "dynamiquement" dans un gabarit (puisqu'on peut controler son affichage 'fixe' avec les 'balises' disponibles).

On dirait vu mon message que je trouve ModX bien trop imparfait pour l'utiliser, mais cependant je persiste avec ModX car il très complet, plutôt rapide, bref il est efficace. Spip est trop lourd pour mon projet, et Textpattern trop léger.

Et si le (l'énorme, à mon goût ) problème dont je parle ci-dessus est un jour réglé, ce serait complètement génial, on pourrait alors dire que ce SGE a tout.

Sinon, elle sera bien la nouvelle interface ?? Pour quand est la prochaine version ?

Loupilo.

(mon ton est parfois sec dans ce post, mais c'est ma nature : il n'y a strictement aucune animosité dans mon message !)

[Luckyluk]

en tout cas,

vos discussions me passionnent et me font decouvrir un peu les joies des particularite des CMS..

je vais encore attendre un peu avant de me lancer car là je sent que je vais ramer...

mais je suis impatient de tester les possibilites de ce CMS

[davidm]

Merci pour ces liens je vais aller voir tout ça

De nada !

Sinon pour que ModX se répande, faut qu'il soit plus simple sur sa syntaxe (enfin actuellement il n'y en a ça simplifie le problème

Pas vraiment d'accord avec toi, là. MODx propose un macro-language basé sur les tags et les tags ont une syntaxe :

[[nom_du_snippet]] (auquel on ajoute des paramètre avec un &nom_du_parametre='valeur_du_parametre' )

[(nom_du_reglage)] (pour insérer la valeur définie dans l'un des paramètres défini dans l'admin)

[*variable_de_modele*] (pour appeler une variable custom)

{{nom_du_chunk}} (pour appeler un bout de code html)

Pour le débat sur la distinction chunks/snippets, petite info en avant première il n'y aura plus de distinction entre les deux mais plusieurs options qu'on pourra sélectionner à l'enregistrement du chunk/snippet (un autre terme unique prendra la place de ceux là, je bosse dessus). En gros un snippet pourra être exécutable ou non, et exécutable soit dans le front-end, soit dans le backend. Assez simlaire aux plugins / admin side plugins dans textpattern.

Je veux dire que le principe des "snippets" qui gèrent l'affichage du contenu c'est un délire (je trouve personnellement que c'est n'importe quoi).

Ouh là attention. Je croyai ça aussi par exemple pour le snippet NewsListing, mais en fait un des paramètres est quel chunk peut être utilisé comme template (ici, on retrouve exactement le même principe que l'appel aux "forms" dans txp).

Je n'ai pas encore regardé tous les snippets, mais de toute façon maitenant que j'ai l'oreille de Ryan, je ne manquerai pas de suggérer quelques modif si cet aspect était défaillant (à moins que tu ne veuilles le faire, je serai ravi de t'avoir dans la communauté ).

Ils devraient s'inspirer de TextPattern : pour obtenir ce qu'il veut, l'utilisateur utilise la syntaxe dispo (ici les <txp>) et peut tout faire avec, il n'a pas pas à appeler des bouts de codes qui choisissent le code HTML qu'ils rendent, ni prier pour qu'un snippet qui fasse ce qu'il veut existe...

Je ne pense pas que ce soit le cas à terme. Il faut bien voir que MODx est lancé depuis mars 2005, même s'il est parti du code d'Etomite, il est encore jeune. Pour l'instant les snippets nécessitent parfois de hacker le code pour contrôler le html en sortie, mais quand je suis arrivé sur textpattern en avril 2004, c'était aussi le cas !

En tout cas, ça me donne des arguments à vérifier et éventuellement à soumettre à l'équipe de dev qui est, soit dit en passant, la plus ouverte aux suggestions et à l'innovation que j'ai rencontré (d'ailleurs, c'est une des choses qui commence à moins me plaire avec textpattern, l'opacité du développement et l'attitude de shérif de Zem vis à vis de certaines remontée de la communauté... mais bon, les développeurs de plugins sont toujours aussi géniaux. Et Textpattern évolue à grande vitesse).

Donc je suis 100% sûr que tes arguments seront entendus, le mieux serait que tu les présente toi même sur le forum ce serait génial

L'utilisateur doit avoir le contrôle dans les modèles de pages et là... ben force est de constater qu'il ne l'a malheureusement pas ! Il doit pouvoir choisir si il veut faire une liste de rubriques, une liste d'articles dans une rubrique, enfin bref il doit pouvoir controller de A à Z où s'affiche ce qu'il veut qui s'affiche !

Il faut distinguer deux choses : la customisation de l'apparence est tout aussi facile avec MODx qu'avec Textpattern et la customisation du contenu qui dépend de la faculté comme tu dis à choisir la structure de l'information. J'ai déjà soulevé qu'il faudrait des tags conditionnels pour sélectionner le contenu à afficher de manière plus flexible, sans passer par un snippet. Je vais lancer un thread à ce sujet.

Ceci dit avant ça, il faut que je comprenne et que j'utilise les widgets .

Widgets (formerly "Display Controls") are quite literally little "specialized widgets" that affect how things are displayed in MODx. In programmer-speak, they are TV components used to format the Input Value to some desired visual output on web sites. The rendered output will vary depending on the selected Widget and the Input Values.

Autrement dit, les widgets permettent de choisir comment on affiche les données customs. Il faudra que je voie si il est pertinent de proposer de les étendres aussi aux variables par défaut...

Et le paradoxe c'est que ModX est incroyablement complet (et c'est bluffant...), que les options d'affichage sont très très complètes (on peut choisir un gabarit par page, si on veut que telle page soit dans le menu, ...), mais qu'en parallèle on ne puisse pas contrôler le contenu "dynamiquement" dans un gabarit (puisqu'on peut controler son affichage 'fixe' avec les 'balises' disponibles).

Je suis assez d'accord.

J'ai bientôt fini un site pour un client avec MODx (ce qui prouve son potentiel, je l'ai découvert le 3 novembre dernier !). Mais je vais être obligé de coder un snippet en php pour afficher des fiches produits...

On dirait vu mon message que je trouve ModX bien trop imparfait pour l'utiliser, mais cependant je persiste avec ModX car il très complet, plutôt rapide, bref il est efficace. Spip est trop lourd pour mon projet, et Textpattern trop léger.

Et si le (l'énorme, à mon goût) problème dont je parle ci-dessus est un jour réglé, ce serait complètement génial, on pourrait alors dire que ce SGE a tout.

Effectivement je partage ton opinion (sauf pour SPIP plus lourd que textpattern, là je ne vois pas car il est beacoup moins puissant !).

C'est pour ça que j'ai investi autant de temps (250 messages en 3 semaines sur les forums MODx, mise au point d'une version pour Free...) dans ce CMS. Etant donné l'ouverture de l'équipe de dév aux suggestions externes, je pense qu'on peut influencer son orientation pour en faire un outil tout à fait exceptionnel.

Le fait de disposer des mots clés comme dans SPIP, des niveaux hierarchiques illimités (que txp n'a pas), des variables customs et surtout (tu n'as peut-être pas encore vu) des widgets qui contrôlent l'affichage de ces dernières... le potentiel est énorme.

Sinon, elle sera bien la nouvelle interface ?? Pour quand est la prochaine version ? 

La nouvelle interface est totalement sans tableaux, skinnable via CSS et celle proposée par défaut est clean et n'a pas grand chose à voir avec celle d'Etomite utilisée par MODx actuellement.

(mon ton est parfois sec dans ce post, mais c'est ma nature : il n'y a strictement aucune animosité dans mon message !)

Pas de soucis je suis pour les critiques, surtout constructives !

Tu m'as donné pleins d'éléments pour donner de l'eau au moulin de Ryan, Raymond et Jason

[Loupilo]

Wow, quelle réponse !

Ouh là attention. Je croyai ça aussi par exemple pour le snippet NewsListing, mais en fait un des paramètres est quel chunk peut être utilisé comme template (ici, on retrouve exactement le même principe que l'appel aux "forms" dans tx

Effectivement pour NewsListing. Ce qui me gène c'est que ce ne soit pas commun à tous les snippets (ben oui, quid de l'absence de ce &tp='menu' pour DropMenu par exemple ?).

Si jamais les snippets continuent à exister (cf point suivant), ils ont alors besoin d'être tous complètement harmonisés...

Encore que la syntaxe utilisée dans le chunk appelé par &tp='dernieresnouvelles' pour NewsListing est bien trop restrictive et ne tient pas la comparaison avec les forms de Textpattern...

Je ne pense pas que ce soit le cas à terme. Il faut bien voir que MODx est lancé depuis mars 2005, même s'il est parti du code d'Etomite, il est encore jeune. Pour l'instant les snippets nécessitent parfois de hacker le code pour contrôler le html en sortie, mais quand je suis arrivé sur textpattern en avril 2004, c'était aussi le cas !

En tout cas, ça me donne des arguments à vérifier et éventuellement à soumettre à l'équipe de dev qui est, soit dit en passant, la plus ouverte aux suggestions et à l'innovation que j'ai rencontré (d'ailleurs, c'est une des choses qui commence à moins me plaire avec textpattern, l'opacité du développement et l'attitude de shérif de Zem vis à vis de certaines remontée de la communauté... mais bon, les développeurs de plugins sont toujours aussi géniaux. Et Textpattern évolue à grande vitesse).

Bon déjà pour moi, les snippets que l'on trouve par défaut sont à éliminer en tant que tels et à inclure "en dur" dans ModX (mais il faut qu'il y ait possibilité d'en créer, ce qui rejoint ton analogie avec Textpattern et ses plug-ins).

Je pense toujours qu'il faut qu'il y ait une séparation entre ce qui fait partie intégrante du SGE (par exemple [[List cat=1" tp="liste]] pour faire une liste des articles de la catégorie 1 suivant l'organisation définie dans le chunk "liste" (qui remarquera la similarité avec TextPattern ?); opération de base qui devrait donc être "dans le noyau") et ce qui est en plus (par exemple [[snippet name=NomDuSnippet" option="option" tp="modeleSnippet]] pour alors utiliser un code PHP "en plus" destiné à ajouter des fonctionnalités).

Mais effectivement ModX est jeune, et je suis impatient de le voir évoluer et j'ai bon espoir.

Il faut distinguer deux choses : la customisation de l'apparence est tout aussi facile avec MODx qu'avec Textpattern et la customisation du contenu qui dépend de la faculté comme tu dis à choisir la structure de l'information. J'ai déjà soulevé qu'il faudrait des tags conditionnels pour sélectionner le contenu à afficher de manière plus flexible, sans passer par un snippet. Je vais lancer un thread à ce sujet.

Question apparence dans le sens "appel de l'information et du contenu là où je veux quand je veux", je ne suis pas d'accord : il n'y a qu'à voir la simplicité avec laquelle on peut mettre en place n'importe quel élément avec TextPattern !

Créer un menu est enfantin (bien sur quand on a compris les <txp>, ce qui n'est pas forcément évident ) avec TextPattern, de la même façon que lister les derniers éléments d'une section X. Ben avec ModX, on n'en est qu'aux balbutiements quand à ce domaine (la domestication complète de tous les éléments composant le site, articles, rubriques, sous-articles dans des sous-rubriques, ...) : par exemple j'ai cherché dans les options de NewsListing et visiblement ce n'est pas possible d'afficher les articles d'une rubrique en passant outre les sous-rubriques !

Bon c'est sur que là, TextPattern ne tient pas la comparaison vu qu'il n'autorise pas les sections imbriquées, mais Spip permet bien sur de faire cela très simplement (toujours à condition d'avoir compris le principe de fonctionnement des <BOUCLE>) et je trouve ça plutôt basique comme fonction.

Bon pour les widgets j'ai rien compris, je repasserai demain en journée quans je serai moins fatigué

Le fait de disposer des mots clés comme dans SPIP, des niveaux hierarchiques illimités (que txp n'a pas), des variables customs et surtout (tu n'as  peut-être pas encore vu) des widgets qui contrôlent l'affichage de ces dernières... le potentiel est énorme.

Je n'en doute pas, seulement, justement, dans Spip, on maitrise entièrement l'affichage du contenu et je trouve ModX encore assez loin de ça (je vais récapituler tous les points précédents, attention ) : snippets non uniformisés, pas (pas tous en cas) assez complets (cf mes critiques de NewsListing) et pas assez généraux. Bref j'aime pas du tout et je n'arrive pas à me faire au principe des chunks et snippets. Autant en moins d'une semaine j'ai compris le gros des <txp>, j'ai affiché le contenu que je voulais sur le site que j'ai lancé avec, et je n'ai besoin de revoir la doc que pour connaître le nom précis des <txp>, autant pour ModX je trouve ça désagréable et vraiment un mauvais système. Mais comme tu le dis, patience

En tout cas c'est clair que ModX avec une syntaxe de TextPattern, je fonce !

Sinon je participerai bien à la communauté sur les forums officiels, mais vu mon niveau en anglais ça risque de faire un massacre !

Remarque on peut toujours essayer, mais moi et la langue de Shakespeare on n'est malheureusement pas très copains... faudra qu'ils soient compréhensifs, là-bas

À bientôt

Loupilo

(ah et pour Spip, ben oui, Spip est un SGE assez lourd : pas une bête de course et certaines fonctions un peu "grasses", mais il reste excellent hein)

[NiCoS]

Vous me donnez bien envie avec tous vos échanges... si seulement j'avais un peu de temps... vivement l'année prochaine...

Modifié 25 Novembre 2005 par NiCoS

[davidm]

(...) En tout cas c'est clair que ModX avec une syntaxe de TextPattern, je fonce !

Attend... j'en découvre tous les jours... je n'avais pas regardé car c"était dans la doc "developper" mais il semblerai que les @bindings contrôlent exactement ce type de test conditionnels.

These Data Sources can be tied (or bound) to a Template Variable for formatting and displaying in document. In addition, the bound data in the TVs can be almost effortlessly formatted via the Display Controls within the TV system for some truly stunning results. The format for using the five types of data source bindings available to all template variables follows:

* @FILE file_path

* @DOCUMENT document_id

* @CHUNK chunk_name

* @SELECT sql_query

* @EVAL php_code

These five @ commands or bindings will allow you to quickly and easily attach your template variables to virtually any database system available.

Il me reste à comprendre le lien entre TV <=> @bindings et TV <=> widgets et utiliser concrètement ces concepts. J'ai un cas concret sous la main, donc je te dirai ça mais il est certain que je parlerai des tags conditionnels et du contrôle de l'affichage des données...

@SELECT me semble être un outil puissant pour construire des requêtes conditionnelles sur mesure... à confirmer.

Sinon je participerai bien à la communauté sur les forums officiels, mais vu mon niveau en anglais ça risque de faire un massacre !

Remarque on peut toujours essayer, mais moi et la langue de Shakespeare on n'est malheureusement pas très copains... faudra qu'ils soient compréhensifs, là-bas

À bientôt

Loupilo

(ah et pour Spip, ben oui, Spip est un SGE assez lourd : pas une bête de course et certaines fonctions un peu "grasses", mais il reste excellent hein)

<{POST_SNAPBACK}>

J'avais pas compris "lourd" dans ce sens là, là je suis d'accord.

Par contre j'ai envie de dire qu'il n'est pas excellent : il l'a été, et il pourrait l'être... même si c'est un peu différent Lodel a ma préférence (tu retrouveras les fameuses boucles qui, c'est vrai, sont bien pratiques et pas trop dures à maîtriser...).

Bon enfin, j'essaye d'appréhender la méthode de MODx pour le contrôle de l'affichage, en jouant avec les widgets et @bindings et je te ferai un feedback. Une fois que j'aurai compris ça je pourrai construire un argumentaire auprès de Ryan, Jason et Raymond pour éventuellement proposer un système à la textpattern

[Loupilo]

Enfin @SELECT, ce sont des requêtes SQL... toujours pas ça selon moi

En attendant je ne vois vraiment pas comment faire pour mon problème de NewsListing (avec une "vraie" syntaxe, le problème ne se poserait pas ) !

Je vais essayer de jouer avec les champs personnalisés, mais bonjour la bidouille alors qu'il y a un super système de dossiers, quel gachis...

Loupilo.

[davidm]

Je vais d'abord aller au fond des choses, et si ce n'est pas satisfaisant, je suis sûr de pouvoir au moins être écouté pour qu'une solution simple soit adoptée pour ce genre de chose...

Je ne suis pas inquiet, ils sont trop malins pour ne pas écouter une demande ou suggestion qui pourrait faire de leur application une application plus flexible