Quelques suggestions.

Bonjour à tous,

Je crains d’être un peu long mais je pense que c’est nécessaire à une bonne compréhension.

Lorsqu’il s’agit de mettre en place un site Internet sans l’aide d’un cms, je crois que l’on peut aujourd’hui considérer qu’au delà des préférences de clocher, ce qui se fait de mieux ressemble à peu près à un logiciel comme Dreamweaver. En conséquence, je crois que tôt ou tard, nous ne couperons pas à la nécessité d’intégrer dans notre cms favori, un éditeur de templates. Je parle d’un éditeur graphique, où pour faire court, les calques imprégnés de chunk, de snippet, d’appels css,... viendraient s’insérer par glisser déposer, un peu à la manière d’une interface flash, pour simuler visuellement le résultat final, en bon wysiwyg. Un genre de Dreamweaver des cms, mais online en quelque sorte.

Au delà de cette remarque préalable, un petit état des lieux.

Depuis maintenant pas mal de temps l’élaboration d’un site web, avec ou sans cms, passe par une étape éprouvante de sélection des technologies qu’il faudra employer. Pour des effets (pertinents ?) quelques fois redondants ou comparables, il s’agit de trier entre les Css, dynamic Css, les différentes bibliothèques Ajax, lightbox, etc, afin de déterminer quoi faire et avec qui. Puis de repérer un cms, quitte à envisager Ruby on Rails, Code Igniter,... qui répond aux attentes choisies.
Tout ceci nécessite une grande dépense de temps, à la fois pour dénicher les technologies en place, pour distinguer les matures des autres, pour évaluer leur devenir, les évolutions promises (et tenues ?), les choisir, les maîtriser, les mettre en place....
Au final, la situation est peu ou prou toujours identique.
- En pratique tous les jours, on se retrouve à utiliser laborieusement des outils de base qui ne font pas exactement ce que l’on désire et laissent inexploités les dernières techniques. D’où, quelques frustrations.
- Frustrations en parties comblées par l’attente d’un code promis comme idyllique mais (généralement) en perpétuel développement. En version béta, allégée des raffinements pour les meilleurs d’entr’eux.

Enfin, lorsque les nouveaux outils tant rêvés apparaissent, s’ils ne se révèlent pas dépassés, nos besoins se sont déplacés vers les nouvelles technologies apparues entre temps. Et le cycle recommence.
Résultat ? On utilise sans arrêt des outils plus ou moins adaptés, et on est perpétuellement en attente des bons. Voilà qui nous coûte du temps et des efforts d’apprentissages. Sans parler des risques de choisir des canards boiteux ou des projets voués à l’échec.

Alors voilà: Pourquoi ne pas déplacer cette étape, au niveau du Cms ?

L’introduction calée sur l’idée d’un éditeur de Templates basait en partie sa pertinence sur l’illustration de cette idée. Je détaille un peu:

Il s’agit de scinder le travail en confiant au niveau du développement du cms la gestion transparente de l’utilisation des différents outils de programmation. Aujourd’hui dans ModX, la fabrication d’un site nécessite l’utilisation d’un template qui, a moins de ne toucher à rien, revient au travers des concepts ModX (chunks snippets, TV,...) à réaliser une sorte d’assemblage de code html, de php, et de js pour faire court, sans avoir à tout écrire directement. En effet, afin de simplifier, ModX introduit donc des objets (chunks, snippets, TV,... ) qui permettent de manipuler le code par morceaux, "un niveau au dessus" en quelques sorte. Tout comme php, html ou un autre langage de "haut niveau" évite d’avoir à tout écrire en assembleur.

Maintenant, remarquons que l’utilisateur de ModX, le webmaster ou un collaborateur avec moins de droits, n’a que faire de savoir s’il manipule du php ou du js. Tout ce qu’il désire c’est un "effet", une action. Et que celui ci corresponde parfaitement à ce qu’il désire obtenir. Par exemple, l’interface d’authentification du login doit être là et pas ailleurs et avoir tel aspect et tel comportement. Que l’effet soit produit par du php ou de l’ajax, quelle importance pour lui ?

Imaginons un éditeur de templates qui manipulerait directement des "effets". On choisirait qu’un calque, (genre un chunk pour parler actuel) apparaît par un effet donné. Prenons l’exemple de "pop pu interne" que produit lightbox par exemple. Et bien on appliquerait tel effet à tel objet (un calque, ou un objet isssue d’un concept à définir). Il s’agit donc bien de dissocier l’effet voulu de la technique utilisé pour l’obtenir. Comme nous allons le constater plus loin ceci va procurer beaucoup d’avantages.

En amont, l’équipe de développement du cms, aurait pour tache de sélectionner les meilleurs outils pour faire telle chose et de développer leur intégration. Rien de bien nouveau. Seul différence, faire en sorte qu’une demande d’effets sur un objet pointe bien sur la technologie choisie pour l’exécuter. On peut aussi imaginer que plusieurs technologies soient intégrées et qu’en option bas niveau, le choix soit laissé à l’administrateur du cms pour savoir sur quoi faire pointer lorsque l’effet est demandé.

Plusieurs avantages à tout ceci:

Tout d’abord, il faut bien comprendre que l’important au final est de permettre à l’utilisateur de cms d’intervenir le moins possible pour savoir quoi utiliser lorsqu’il décide d’un effet. D’où un gain de temps et un meilleur ciblage sur la créativité. Que chacun soit utilisé là ou il est le meilleur. La veille technologique et son intégration étant réalisé en commun au niveau du cms, par les meilleurs et une fois pour toute. On peut objecter que ceci est déjà le cas, mais ici les progrès vont bien au delà.

En effet, que ce passe-t-il lorsque débarque une nouveauté comme Css 3 ou Ajax bis ? En fait Ajax n’est pas nouveau mais c’est pour prendre un exemple. Appelons là "Javel". Tous les cms vont s’y mettre, moyennant plusieurs mois (années ?) de développement. Des cms Javel ready vont apparaître. D’autres "tout Javel". Ca va prendre du temps, ce ne sera pas forcément pertinent et le jour ou les premiers arriveront, ils ne seront pas conformes aux attentes par d’autres aspects que les nouveautés. Des acquis précédents auront été perdus entre temps.

Que se passerait il dans notre cas à nous ? Nous décidons que Javel peut être utile et les développeurs intègrent la bibliothèque. Ils font simplement pointer les effets existants qui gagnent à être Javellisés depuis l’éditeur vers les nouvelles bibliothèques et mettent en place quelques icônes pour les nouveaux effets possibles. Pas de nouvelle interface à penser, juste une intégration, des ajouts de possibilités. Bref, juste un choix de pointage supplémentaire.
Que fait l’utilisateur ? Une mise à jour du cms lui permettra de pointer ses effets existants sur la nouvelle technologie et d’en disposer de nouveaux s’il désire les utiliser. Et c’est tout ! En somme l’écriture du site ne change pas pour le webmater. Ce sont toujours les mêmes effets qui sont employés et montrés depuis l’interface. On acquiert une plus grande indépendance vis à vis des outils techniques utilisés.

Outre le confort de l’utlilsateur, la réactivité et le gain de temps on peut citer la minimisation des risques dans les choix faits en communs par meilleurs que soit. Un mauvais choix d’une technologie finalement décevante coûte le temps de l’intégration par l’équipe des développeurs. Alors que dans un cas classique, elle aurait coûté la même chose plus la conception de son intégration au niveau des développeurs. Plus les temps d’apprentissage de toute la communauté qui doit apprendre à l’utiliser...

Et ce n’est pas fini:
Quoi de plus désagréable et démotivant pour un développeur d’avoir toujours à (re) développer les même effets ? Parce que l’équipe mal conseillée, mal renseignée, effectue des mauvais choix de développements ou les conduit mal, parce qu’elle change d’orientation en permanence, parce qu’en fin de compte tout ceci amène gaspillage et pertes de temps qui rendent le code final dépassé et obsolète. Donc inutilisé. Tout ceci un coup en css, un autre avec du js, le tout une nouvelle fois pour un nouveau cms qui tue la mort. Et enfin une autre fois parce que l’équipe d’ego sur-dimensionnés s’est évaporée et qu’il faut tout recommencer sur un autre projet.

Au contraire, un développeur qui emploierait son temps à travailler dans le cadre décrit plus haut, aurait davantage l’assurance de voir son code véritablement utilisé, et surtout au maximum de son potentiel. Tout ceci avec un rapport efficacité / coût-de-développements inégalé qui ne manquerait pas d’augmenter l’attrait du cms auprès des développeurs de qualité conformément au sujet déjà évoqué précédemment. Le cercle vertueux à mettre en place au niveau de l’attrait pour de nouveaux développeurs de qualité prendrait ainsi naturellement sa source au niveau d’un autre cercle vertueux mis en place au niveau du code. Bien pensé, développé, rapidement mis en place et surtout bien exploité par l’utilisateur final, déployant ainsi toutes les qualités du travail amont.

Dans cette optique, on comprend bien que la partie cruciale se situe au niveau de l’éditeur de templates. En particulier, le tableau ne serait pas complet si cet éditeur de templates n’était pas véritablement pensé. Je devrais dire "repensé" au regard de ce qui nous familier aujourd’hui. Car c’est à ce niveau, qu’il y a le plus à gagner si l’on décide d’uiliser les idées précédentes. En effet il me faut admettre que quelques idées (à creuser) me trottent dans la tête depuis quelques temps et que poursuivre l’échafaudage d’un cahier des charges pourrait être intéressant.

Mon laïus étant déjà bien long, si la suite peut être utile et vous intéresse je peux essayer de poursuivre prochainement à propos de cet éditeur de templates. Faites le moi savoir en plus de vos commentaires. Dans le cas contraire pas de problème, je tâcherai de passer à autre chose.

John Steed.

Tes suggestions sont très intéressantes John, mais concrétement elles concernent la sphère des développeurs du (des) produits, plus précisemment les fondateurs qui oriente les choix strtégiques de MODx.

Je ne suis pas en mesure de répondre à tes suggestions, mais il faudrait qu’une personne comme David traduise tes idées et les rapporte coté anglais (à moins que tu sois en mesure de le traduire toi même).
Mais j’avoue que je suis intéressé pour connaître la suite et les autres commentaires sur le sujet.

Salut,

En fait, je ne me voyais pas en train de m’inviter au milieu des développeurs qui ont sans doute autre chose à faire, en plus de savoir ce qu’ils font. Peut être que ce genre de suggestions ont déjà été évaluées et écartées, peut être pas. Je n’en sais rien.

Mon propos était simplement de poser sur la table, en partage, quelques idées. A charge à votre équipe de les reprendre et les exploiter si nécessaire. Je ne sais pas si les développeurs scannent les sujets du forum ou si des personnes sont censées relayer les idées potentielles. En réalité je ne sais pas comment l’organisation fonctionne à ce niveau là.

Une chose est sûre, avant de déranger l’équipe qui travaille, je pensais plus utile d’exprimer quelques pensées à la vue de tout le monde. (enfin ceux que ça intéressent). J’ai sans doute bien fait de ce côté là parce qu’en matière de commentaires, ça n’a pas l’air de soulever les foules. Donc avant d’aller un cran au dessus, autant essayer de cerner le sujet. Une chose est certaine cependant c’est que ça concerne bien la refflexion "amont" du cms, mais ça me semble une étape cruciale et déterminante du projet, alors autant la paufiner.

John Steed.

Bonjour John,

vaste question que tu poses ici, et très belle vision de ce que sera probablement le CMS du futur à plus ou moins long terme.

Bravo pour ce post, même si il est en effet plus destinée à la sphère citée par Marc. Et je suis bien entendu interressé par la suite.

Une petite remarque toutefois : lorsque tu parles de reflexion en "amont" (je pense notamment à ton idée d’éditeur de template), ne pourrait-t-on pas envisager une solution en "aval" , par l’intermédiaire d’un pluggin par exemple ?

Je suis tout à fait conscient qu’un travail en amont est une bonne idée (d’ailleurs, tout travail en amont est une bonne idée), mais j’éprouve une certaine crainte à voir se fondre le modèle logique avec le modèle de représentation des données le cas échéant.

Bonne journée

Johnsteed, bien sûr ces idées sont très intéressantes, n’hésite pas à les soumettre à notre équipe de dév, peut-être après la sortie de la 0.9.5. Ryan et Jason ont toujours été très preneurs d’idées nouvelles, de suggestions et très ouvert sur le sujet.

Par contre par rapport à l’idéal que tu décris (le web 3.0 ?), il ne fait pas du tout partie de l’approche de MODx et encore moins de MODx 1.0 / Tattoo.

La plupart des développeurs et designers travaillent maintenant quasi exclusivement à l’aide d’éditeurs de texte puissants comme TextMate sur Mac, PS Pad sur windows, leur permettant de travailler directement le code de la manière la plus efficace possible. Pour avoir commencé avec Dreamweaver il y a 8 ans, je dois dire que plus mes compétences se sont développées, plus j’ai ressenti les limitations de l’outil WIWYSYG. C’est particulièrement vrai si l’on considère que le développement web moderne signifie conformité aux standard, accessibilité et balisage sémantique. Il reste difficile (sauf à repasser derrière à la main) de produire un code propre avec des outils comme dreamweaver. Peut-être un jour arriveront nous à avoir des éditeurs WYSIWYG réellement dignes de ce nom, mais la création web est encore totalement opposée à la création en PAO par exemple ou la sémantique est complètement fusionnée avec l’apparence.

Transposer la logique "à la Dreamweaver" dans un CMS me semble très ambitieux et honnêtement ca ne peut être un bon choix que si l’on vise l’utilisateur final. C’est le pari fait par iXprim (éditeur de template WYSIWYG) et je n’ai pas eu le temps de vérifier ce que cela rend. Ca pourra peut-être t’intéresser :

(...) La principale caractéristique d’iXprim c’est son système de template créé pour être le plus simple possible. Il y a biensûr quelques règles à respecter, mais, cela je vous le certifie, votre template sera COMPLETEMENT visible dans un éditeur WYSIWYG.
Quand je dis complètement, cela veut dire, que textes, images, javascripts,... sont complètement visibles dans le template. Vous n’avez pas à vous soucier du path (chemin) des images, ixprim le prendra en compte automatiquement et génèrera le cache en conséquence. Vous trouverez en download le thème original de iXprim et vous verrez par vous même. (...)

En ce qui concerne MODx le choix est fait et bien fait : il cible des développeurs, les webdesigners et les passionnés qui n’ont pas peur de mettre les mains dans le cambouis... C’est donc un positionnement diamétralement opposé à celui dont tu parles dans ta vision du CMS idéal.

Le but des fondateurs de MODx, Ryan, Jason, Raymond est bien d’offrir l’outil le plus flexible qui soit pour que les professionnels puissent s’affranchir des limitations des systèmes moins flexibles qui innondent le marché des CMS. Au départ, ils l’ont créé pour leur propres besoins en tant que professionnels du web car ils étaient frustrés par les Joomla, les Typo3 et autres usines à gaz trop rigides.

Le problème de beaucoup de CMS c’est qu’ils ne ciblent pas la bonne cible : ils cherchent à permettre à des personnes non techniques de créér et modifier des sites web facilement, et un bon exemple de dérive rigidifiante c’est l’émergence du système des "blocs" qu’on peut placer à droite, au centre à gauche en modifiant un simple réglage d’admin. D’où le reproche des designs standardisés, des structure de page et de données, uniformes et récurrente. Pas gênant pour un CMS "perso" mais pour du "pro", c’est plutôt un outil comme MODx qui convient mieux. Car il est pensé pour le prestataire ! Au lieu de de bloquer dans un modèle nécessairement moins flexible puisque pré-paramétré, il donne toute liberté au designer de placer et styler le code exactement comme il veut (respectant ainsi un des principes fondateur du web moderne : la séparation du contenu et de la présentation).

Maintenant attention, ça ne veut pas dire qu’il ne faut par rendre les CMS facilement utilisables par des néophytes, mais il ne faut pas se tromper de fonctionnalité : c’est le contenu que l’utilisateur final doit contrôler (QuickEdit est un gros plus dans ce domaine), pas la présentation (c’est là que je suis en désaccord avec iXprim -> en tout cas pour des sites pros) ! Evidemment, l’utilisateur final à la main sur certains éléments de style, ou par exemple en ce qui me concerne je créé une TV pour permettre à mon client de modifier l’image d’entête de ces pages mais PAS la mise en page elle même.

Concernant la ré-utilisation d’éléments et l’efficacité du cycle de développement, je pense qu’il faut dissocier automatisation et modularisation. Quand tu dis quoi de plus fatiguant que de re-coder plusieurs fois la même chose : c’est justement l’avantage d’avoir une API, et aussi d’avoir un contenu aussi ré-utilisable et une architecture aussi modulaire que possible.

MODx a selon moi un avantage compétitif assez significatif. La ré-utilisation de bouts de code grâce aux chunks est un grand plus. Les CSS dynamiques permettent de ré-utiliser des bouts de CSS pour recomposer des feuilles de styles utilisant des éléments communs qu’il suffit d’éditer à un endroit pour actualiser toutes les pages (idem, pour les chemins d’accès aux images).

Ceci dit et pour conclure, rien n’empêche de concevoir des extensions permettant de rendre la tâche plus facile au néophyte : Scotty a fait beaucoup en ce sens que ce soit avec l’installateur de template SkinGraft ou avec le Resources Wizard... Ce principe pourrait être étendu post 1.0 puisqu’il sera facile de créer des distributions de MODx à vocation différentes (blog, webzine, portail...etc).

Je vais tâcher de répondre dans l’ordre

Une petite remarque toutefois : lorsque tu parles de reflexion en "amont" (je pense notamment à ton idée d’éditeur de template), ne pourrait-t-on pas envisager une solution en "aval" , par l’intermédiaire d’un pluggin par exemple ?

Il faut que je réfléchisse davantage pour répondre à ça de manière sûre. Mais, spontanément, il me semble que l’imbrication serait telle que pour les développeurs en tire un maximum d’avantages, il s’agirait de concevoir l’ensemble (en fait une partie du cms) sachant qu’un plugin de ce genre là est appelé à venir se greffer. Ca demande confirmation(s).

j’éprouve une certaine crainte à voir se fondre le modèle logique avec le modèle de représentation des données le cas échéant.

Je partage cette crainte. Mais j’ai dernièrement fait évoluer mes convictions. En effet, il peut arriver que le modèle logique soit si touffu qu’il en devienne illisible. Et dans ce cas là, un bon modèle de représentation des données permet de s’affranchir de ce bourbier.

La plupart des développeurs et designers travaillent maintenant quasi exclusivement à l’aide d’éditeurs de texte puissants comme TextMate sur Mac, PS Pad sur windows, leur permettant de travailler directement le code de la manière la plus efficace possible.

C’est vrai. Mais, il s’agit de code dans ce cas là. Et il est bien difficile à ma connaissance avec ces outils ou des équivalents de valider le rendu graphique obtenu. Ne serait pour voir "ce que ça donne". Si les images sont bien jointives, les polices de tailles appropriées... Pour être franc, ils ne sont pas fait pour ça, donc difficile de le leur reprocher, mais il me semble qu’ils montrent leurs limites face à ce que je vais essayer de re expliquer plus loin.

En ce qui concerne MODx le choix est fait et bien fait : il cible des développeurs, les webdesigners et les passionnés qui n’ont pas peur de mettre les mains dans le cambouis... C’est donc un positionnement diamétralement opposé à celui dont tu parles dans ta vision du CMS idéal.

C’est là qu’on ne se comprend plus. Soit vous m’avez lu un peu vite, soit ce qui est plus probable, je me suis mal exprimé. Je ne parle absolument pas de web 3.0 ou d’un cms idéal. Il s’agit simplement de voir comment mieux parvenir à utiliser les capacités de personnalisation de ModX.

En fait ce que j’ai exprimé n’est absolument pas opposé au choix fait par ModX. Si j’ai posté dans ce forum, ce n’est d’ailleurs pas par hasard.
Pour moi, la force N°1 de ModX est de ne fermer aucune possibilité. Tout est permi, y compris de descendre dans le code pour bricoler soit même. Adapter un template par page est ici une banalité que bon nombre de cms n’envisagent même pas. D’avoir voulu simplifier la gestion de contenus, ils en ont restreints les libertés d’actions. Ce qu’ils ont gagné dans un sens ils l’ont perdu dans l’autre. Vous le dites à votre manière à propos de Typo3 (encore que ça pourrait changer parait il ?) ou de joomla, incroyablement bridé face à ModX.

Non, si pour résumer, je devais reprendre les phrases clés de mon message ce seraient celles ci:

Il s’agit donc bien de dissocier l’effet voulu de la technique utilisé pour l’obtenir. Il s’agit de scinder le travail en confiant au niveau du développement du cms la gestion transparente de l’utilisation des différents outils de programmation.

Il ne s’agit absolument pas de restreindre les capacités d’adaptation ou de bricolage du cms. En fait il n’y a rien à perdre et tout à gagner.

Je prends un exemple: Utiliser un cms classique est plus simple que de tout programmer à la main en php, html,.... En revanche, on perd en précision, c’est à dire, que l’on peut moins personnaliser. On est obligé de se contenter de manipuler des "gros bouts". Si les développeurs ont prévu des tas d’options ci et là, ça peut palier, un peu cet effet. Mais il est toujours présent. En définitive, plus on descend vers le code, plus on gagne en flexibilités, mais plus on perd en confort. C’est l’un ou l’autre et une affaire de compromis dans lequel ModX a choisi de maximiser les possibilités au détriment, assumé, du confort. On est d’accord là dessus. On cible bien les mêmes personnes.

Or, mon post de parle pas (tout à fait) de ça. J’essais simplement de réfléchir à comment gagner en flexibilité sans (trop) perdre de confort. Bref, j’essaie de trouver une solution pour sortir du carcan "confort x possibilités = constante". Il s’agit donc d’explorer des solutions, des concepts pour pouvoir (comme aujourd’hui) tout permettre à ModX, mais sans avoir à triffouiller systématiquement dans le code. Bien sûr si on désire y aller, pourquoi pas, mais des cas pourraient être résolus sans que ce soit nécessaire.

c’est le contenu que l’utilisateur final doit contrôler

On est bien d’accord là dessus. J’aurais même dit "c’est uniquement le contenu....." pour l’utilisateur de base. On peut aussi imaginer un niveau d’utilisateur supérieur autorisé à en faire davantage (vous le dites vous même ensuite), mais l’utilisateur de base est celui que vous mentionnez.

Quand tu dis quoi de plus fatiguant que de re-coder plusieurs fois la même chose : c’est justement l’avantage d’avoir une API, et aussi d’avoir un contenu aussi ré-utilisable et une architecture aussi modulaire que possible.

On ne parle pas de la même chose, mais c’est secondaire ici. Quand je parlais d’avoir à re-coder, je pensais au développeur qui se retape, pour la xième fois le développement d’un plugin pour installer automatiquement des extensions par exemple. Il le fait pour la version 1, puis ça doit changer pour la 2 because c’est plus compatible... etc... c’est du ressort de la mauvaise gestion de l’équipe de développeur et ça démotive. J’en parlais parce que ça intervenait dans mes arguments mais c’est un sujet un peu en marge de l’essentiel de mon propos.

La ré-utilisation de bouts de code grâce aux chunks est un grand plus. Les CSS dynamiques permettent de ré-utiliser des bouts de CSS pour recomposer des feuilles de styles utilisant des éléments communs qu’il suffit d’éditer à un endroit pour actualiser toutes les pages (idem, pour les chemins d’accès aux images).

On est encore d’accord là dessus. C’est bien ça dont il s’agit d’etendre les possibilités et le principe, tout en ne restreignant aucune flexibilité.

John.

Bonjour,

Pour moi qui ne suit pas un hard coder, je dirais que Modx se place entre le Framework pur et dur et le RTP (ready to Publish)
Il permet à des personnes de mon niveau d’avoir accès à une grande liberté de conception tout en restant accessible pour peu que l’on veuille bien appréhender sa philosophie.

Dreamweaver et autre, je ne les utilisent plus depuis de nombreuses années. Peronnellement, je fais tout avec PSPAD et quand je veux vérifier mon travail, je fais une prévisualisation dans un browser ou via un serveur web local. Pour moi, un éditeur de Template est une absurdité. Concevoir un template dans un CMS est très souvent une perte de temps. Pour moi la conception du "design" doit être réalisé bien avant l’étape de mise en ligne. Maquette Gimp, génération de pages statiques pour visualiser le rendu. Une fois cettte étape validé alors je traduis en CMS mais jamais avant.

J’essais simplement de réfléchir à comment gagner en flexibilité sans (trop) perdre de confort.

Ce ne serait pas l’inverse.
Personnelement, je ne touche pas le core code. Pour des besoins précis j’utilise l’API et si je ne trouve pas mon bonheur, j’utilise des class existante ou je la crée.

Concernant l’API, je rejoins David, et son évolution me semble irrémédiable. Maintenir une compatiblité descendante est une erreur car elle bride les possibilités d’évolutions. Une montée de version demande toujours un travail de fond mais cette dernière n’est jamais obligatoire tant que la version actuelle du CMS correspond aux besoins.

A plus

Re salut,

Pour moi la conception du "design" doit être réalisé bien avant l’étape de mise en ligne. Maquette Gimp, génération de pages statiques pour visualiser le rendu.

Je suis d’accord sauf que de plus en plus, le design devient dynamique. Par conséquent c’est d’essayer de le visualiser avec des pages statiques qui devient une absurdité.
Secundo, un éditeur de template, n’est pas dans mon esprit uniquement destiné au design. Ce serait même stupide de l’envisger ainsi puisqu’un template sous ModX peut contenir du code. (dites moi si je me trompe). Dans mon esprit encore une fois, l’éditeur de template et un outils de programmation. On y fait du design, du html, de l’Ajax mais "sans le savoir" en quelque sorte si c’est bien pensé. Et si on veut quand même le faire à la main, on doit le pouvoir aussi.

Ce ne serait pas l’inverse.

Alors tout dépend comment on comprends ma phrase en effet. Disons que sous ModX la flexibilité est totale puisqu’on peut tout faire. Distinguons deux cas:
- Vous savez programmer en php, en Ajax... . La flexibilité est déjà totale avec ModX. L’idée et de continuer à pouvoir tout faire, mais avec plus de confort. Gain limité.
- Vous être plus limité dans les languages précédents: Actuellement, vous êtes en partie tributaire de vos compétence. Je dis en partie parce que ModX ne nécessite pas fondamentalement de faire du php. Mais si vous savez, ce ne sera que mieux. L’éditeur de template vous permet d’accèder au pilotage de tous les langages à travers une seule interface.

En fait, je me rends compte d’une chose. C’est que l’éditeur de template tel que je l’imagine s’apparente à la création d’un langage propriétaire ModX (dans mon esprit c’était un nouveau concept), qui regrouperait à la fois le pilotage de tous les langages qui peuvent intervenir dans la page web. Sachant que lorsque ces languages évoluent, le langage "propriétaire ModX" lui évolu un minimum ce qui limite les addaptations à faire au niveau du webmaster.

Je suis d’accord sauf que de plus en plus, le design devient dynamique. Par conséquent c’est d’essayer de le visualiser avec des pages statiques qui devient une absurdité.

je suis désolé mais, quelque soit l’outil, le language utilisé, le contenu d’une page web est statique. Le css et le js permettent toute au plus de modifer le design et le comportement mais le contenu reste le même. CSSZenGarden en est un bon exemple.
Donc avoir une panoplie de pages statiques que tu fais évoluer en modifiant juste tes css et js n’a rien de ridicule bien au contraire.
Comme je le disais ci dessus, je ne consois pas de créer un template sous modx sans l’avoir conçu avant.

Ce serait même stupide de l’envisger ainsi puisqu’un template sous ModX peut contenir du code. (dites moi si je me trompe). Dans mon esprit encore une fois, l’éditeur de template et un outils de programmation

Non, les templates Modx ne contiennent pas de code au sens php ou autre language.
Il contient ce que tu sembles vouloir, le language propriétaire Modx, c’est à dire des tags qui te permettent d’appeler des snippets, variables, TV, chunk .... Et le nouveau parser te permettra de faire du recursif.

Quand à faire du dev sous modx, pourquoi? Il existe de très bon outils pour cela qui t’offre de nombreuses fonctionnalités, debug ...
Tu peux même développer en live en utilisant par exemple :

Bon décidément, on ne se comprends pas. J’ai l’impression de parler d’un sujet A et que l’on me répond sur un sujet B. (Sauf pour Olivier)

je suis désolé mais, quelque soit l’outil, le language utilisé, le contenu d’une page web est statique.

Je ne parle pas du contenu ! Mais des éléments qui le déploient. Si on a une zone qui lorsque l’on clique dessus bouge pour montrer un supplément de texte, en utilisant Ajax par exemple. Il y a quelque part un appel à du js pour faire un mouvement sur une partie de la page suite à un clic de souris. Vous n’appelez pas ça un comportement dynamique ? Peut être que je n’utilise pas les bons termes alors.

Donc avoir une panoplie de pages statiques que tu fais évoluer en modifiant juste tes css et js n’a rien de ridicule bien au contraire.

Je n’ai jamais dit le contraire. Le css est généralement utilisé pour faire de la mise en page figé. Mais pour revenir à l’exemple précédent, voir l’impact de l’utilisation de l’effet Ajax sur la page depuis l’écriture du code ne me parait pas simple. Il faut forcément avoir un site en local et le tester dans un navigateur il me semble.

Mais encore une fois, (je me répète) on est pas au centre du sujet que je voulais aborder.

Non, les templates Modx ne contiennent pas de code au sens php ou autre language.

Dans un template, on trouve bien des snippets, appelé suivant une syntaxe genre [* *]... Or un snippet, si on en a envie, c’est bien du php ? ( n’hésitez pas à me dire si je me trompe encore une fois). Donc il y a bien du php (ou du js) dans un template. C’est juste un jeu d’écriture.
Il me semblait avoir compris qu’un chunk c’était un appel à du html pur et que les snippets pouvait contenir du php. Si ce n’est pas ça, alors je n’ai rien compris.

Ce que je voulais imaginer, c’est de faire en sorte que ce jeu d’écriture soit pensé de telle sorte que primo, il devienne indépendant du langage appelé. Et secundo, qu’il permette d’accéder à une forme de programmation, comme si on descendait dans le code un cran au dessous, sauf que l’on devient indépendant de l’évolution de ces langages.

$snipPath = $modx->config[’base_path’] . "assets/snippets/sendform/";
include_once $snipPath."sendform.inc.php";
return $output;

Bingo. Voilà un exemple avec un code rigoureusement hermétique pour moi. C’est exactement le genre de chose que je cherche à pouvoir faire depuis cet hypothétique éditeur de templates. Sauf que l’on pratiquerait cette programmation sans faire du php directement comme ici. Et que le rendu serait immédiatement visible. Suis je clair ? ou pas ?

Ici ce code "fait" quelque chose. Moi là, je ne suis pas capable de vous dire ce qu’il fait. (enfin si, il a l’air d’expédier un formulaire, quoique...) Bref, l’utilité de l’éditeur de templates, serait de permettre à l’utilisateur (le webmaster ModX) de contruire ce code à travers une interface ergonomique qui lui ferait comprendre d’emblé ce qu’il fait (sans pour autant connaître php). L’éditeur transformerait alors cette construction en du code php tel que vous avez écrit pour le système, puisque de toutes façons, c’est bien à ça qu’il faut obtenir au final pour que ça marche. Est ce plus clair ?

Sur ce, dodo pour ce soir.
++