date format français

Bien le bonjour à vous,

Discution très intéressante au niveau des dates (je parfais mes connaissances PHP, merci ). Je serais curieux en revanche de savoir ce que cela implique niveau performances!

Pour Revo, si je peux me permettre, je vous conseille te tester la 2.1.0 : beaucoup d’améliorations côté performances (surtout au niveau du cache) aussi bien en back qu’en front. Enfin mon point de vue est loin d’être objectif (je suis accro à Revo et ses capacités, j’en ai mis Evo aux oubliettes - bien qu’il soit un exellent produit).

Bonne fin de « week-end » à vous.

Salut Romain,

honnêtement, en terme de perf, l’impact est quasi nul.
Sur la plupart des sites que je fais, because en français pour l’essentiel j’use et j’abuse de ce snippet (les clients aiment les dates qui s’affichent de façon humaine et lisibles...) et, franchement, les pages qui l’utilisent ne se chargent pas plus lentement que celles qui ne le font pas.
En réalité, php va très très vite quand on lui faire juste le boulot nécessaire sans circonvolutions...

Pour Revo, perso, j’avoue que j’avais aussi craqué, notamment sur l’interface du back que je trouvais plus belle et simple (si c’est possible) que celle de Evo.
Il y a plusieurs choses que je n’aime pas en revanche

- Ext (leur licence est bancale et son devenir incertain, pas celui de la librairie mais celui de sa licence).
En plus, c’est une usine à gaz dont la seule qualité (à mes yeux) est d’implémenter un système de class un peu comme Mootools (en moins bien oeuf corse ) ou YUI dont elle est plus qu’inspirée. Je ne comprends pas ce choix j’avoue mais bon...

- xPDO, PDO = great, x = moins great , je suis allergique à xml que je trouve lourd et illisible la où JSON est tellement plus propre, voire php tout simplement
intéressant d’ailleurs de lire le pourquoi les dev du framework Yii (un des très gros frameworks php et un des plus rapides...) ont viré tout ce qui était xml pour un fichier de config php

- la relative complexité pour installer un simple module.
Dans tous mes sites boulot je développe une palanquée de modules et les installer dans Evo prend 30 sec, dans Revo, ce n’est pas vraiment la même...

mais honnêtement, je serais passé au-delà de tout ça si ce n’avait été cette lenteur chronique du front.
Maintenant, j’ai lu que les dernières releases amélioraient considérablement l’affaire et j’allais foncer sur la 2.1 et voilà que hop, déboire sur la RC2 et la RC3 qui tarde à passer en PL.

Attention, je ne critique pas, loin de là je suis même assez admiratif du boulot des devs même quand je ne partage pas leur point de vue (x de xPDO par ex ) mais, pour moi, un autre gros avantage d’Evo est que les plâtres ont été pas mal essuyés... pour être honnête, j’ai commencé à me dire que OK, je pouvais l’utiliser pour le boulot à partir de la 1.03 !!!
Pour le moment Revo, qui sera sans doute the one and the only un de ces jours, souffre un peu des déboires normaux de l’adolescence, il nous fait sa petite crise d’acnée mais sera beau un jour, c’est sûr

Dernier point pour moi, j’avoue que mon plus gros manque avec MODx est l’absence de gestion multilingue native, du coup, avec Evo et YAMS, je m’en sors très bien (c’est vraiment top) mais je lorgne avidement du côté de Ionize Cms dont la gestion des langues est hallucinante.
Du coup, faut choisir quoi apprendre, Revo multilingue nativement (et avec un moteur de recherche qui attaque les tables persos, soyons fous), j’y vais sans hésiter, MODx est le seul CMS dans lequel j’accepte de faire des sites pros pour le moment (j’ai même fait passer deux agences dessus et la toute jeune mienne, l’agence, pas moi... est MODx déclarée et militante), mais faute de ça, la gestion des langues de Ionize... (qui vient avec Codeigniter comme framework pour développer...) ça fait réfléchir

voilou, intéressante discussion hors php aussi tu vois et je suis preneur de tout argument qui me fera rester MODx exclusif

Have swing

Virtualgadjo,

note: je pense que nous allons dévier du sujet initial…

Merci pour ton retour sur les performances de ton snippet.

Concernant, Revo, ne maîtrisant pas le sujet (ExtJS, la licence…) je ne me prononcerais pas.
En revanche, je te rejoint sur le fait que cela semble être une usine à gaz. Maintenant, je suppose que les devs ont fait ce choix pour une bonne raison. N’étant pas développeur à proprement parler (mais je me soigne!), ce que j’ai pu comprendre comme étant un avantage, c’est qu’avec MODExt (ExtJS pour Revo), tu peux accéder à l’objet $modx directement (cf. http://rtfm.modx.com/display/revolution20/MODExt+MODx+Object). J’ose (soyons fou!) imaginer le gain de temps que cela doit représenter lorsque l’on développe un composant!

Pour les composants/modules, je trouve l’installation sous Revo bien plus aisée. Là où il fallait « bidouiller » sous Evo (ce qui a son charme), il suffit de quelques clics sous Revo (je ne parle même pas de l’automatisation d’installation de composants quasi « obligatoires » comme getResources, Wayfinder…).

Je te rejoint également sur le « manque » de maturité de Revolution. Mais n’est-ce pas notre « devoir » que d’aider en rapportant les bugs rencontrés, soumettant des suggestions/features requests, … ?
Mon implication dans le monde Open Source est également tout récent, mais je pense que c’est de cette façon que l’on peu arriver plus rapidement à la maturité d’un logiciel.

Maintenant, au sujet du multilinguisme (je dirais même multi-sites, via les contextes), Revo gère cela « nativement » bien mieux qu’Evo selon moi. L’extra Babel vient même rendre la tâche encore plus aisée aussi bien pour le développeur que pour l’éditeur du site (reste toujours ce problème de locales, sujet initial de ce thread d’ailleurs, solutionnable via un plugin).

Enfin, pour le moteur de recherche, la roadmap de SimpleSearch fait état de recherches possibles dans des bases externes. J’ai eu ouie dire qu’un dérivé d’AjaxSearch serait en route… Mais effectivement, rien d’utilisable à ce jour.

Encore une fois, mes propos sont forcement biaisés. Je me met au développement « à cause » de Revolution, qui me laisse entrevoir des possibilités énormes (mais il faut mettre les mains dans le code) et suis donc hautement influencé par les recommandations & choix des développeurs. Peut-être reverais-je ma copie lorsque je serais un true dev

:) tu as raison, je pense que nous dévions un peu mais je suis sûr qu’Epy ne nous en voudra pas trop...

Pour Ext, j’avoue ne pas avoir fouillé plus que ça, depuis son rachat et sa double licence je me suis écarté de cette librairie mais, comme tu dis, j’imagine que les devs ont leur raison et, au-delà de son côté usine à gaz et de sa lourdeur, allez laissons-lui au moins le bénéfice de l’écriture objet

Allez soyons honnêtes aussi, je suis arrivé sur MODx en cherchant un cms nativement basé sur Mootools et l’abandon de Mootools pour ext m’a chiffoné
à ce sujet d’ailleurs, c’est intéressant de voir ce que Ionize fais avec mootools et mocha UI dans son back, clean et efficace (et non, je ne suis pas arrivé sur ionize en cherchant un nouveau cms avec mootools natif mais un construit sur codeigniter...)

là où je te suis moins c’est pour l’install des modules sur Evo, je ne vois pas où est la bidouille.
Quand j’écris un module perso, je le fais intégralement dans son dossier, je fais un appel à la page index du module

dans le gestionnaire, et hop le module est fonctionnel !
j’en ai comme ça une floppée, certain complètement objet en php5 pour la gestion des images, d’autres plus procéduraux parce que plus simples mais j’avoue que l’install me régale (même si elle est dûe au grand satan, le frameset, mais dans le back... entre le frameset et la génération de html/canvas/vml par js, honnêtement...)

je pense que tu fais plutôt référence aux divers modules/snippets/plugins dispos sur le site et à la façon de les installer à la main (mais regarde l’install de editarea avec son isntallateur à la modx, c’était faisable) dans Evo comparé au package manager de Revo, c’est vrai, très agréable avec en plus les mises à jours auto, great ça !
En revanche, je ne sais pas si tu t’es lancé dans le dev/install de modules/custom manager pages comme ils s’appellent dans Revo mais c’est un peu le parcours du combattant

100% d’accord avec toi en revanche sur le côté open source et le côté contributif, j’ai fait ce choix aussi et essaie de remonter autant de choses que possible.
En revanche, je suis malheureusement contraint par le boulot à aller vite et à faire efficace, du coup, mon choix se porte vers des solutions éprouvées tout en faisant mon possible pour y contribuer autant que je le peux

J’ai effectivement lu un peu sur Babel et c’est très tentant, l’utilisation de context rendant l’histoire vraiment intéressante (d’où ma hâte de voir la 2.1 en PL pour essayer )

Vu aussi pour les moteurs de recherche, et oui, coroico est en train de plancher sévèrement sur un portage d’AjaxSearch sur Revo, ça aussi promet d’être très intéressant

Et non, je ne pense pas que ton point de vue change au fil de ta plongée dans le dev au contraire, Revo est certainement encore plus destiné aux dev qu’Evo
j’avoue juste qu’à ce sujet, autant MODx est vraiment le seul cms avec lequel je travaille parce que fabuleux pour les clients (faire la démo et la prise en main de MODx pour un client est toujours un pur régal) autant j’ai eu aussi un moment de flottement en voyant arriver Revo et ai pensé "pourquoi redévelopper MODx en refaisant un framework au lieu de s’appuyer sur un des poids lourds du genre, Yii ou CodeIgniter ? (je choisis les rapides au hasard... )"
mais bon, j’ai cru comprendre qu’il y avait dans la bandes quelques QI de compétition (dont Jason Coward l’auteur de xPDO par ex) et je pense (et peux comprendre...) qu’ils se font un peu plaisir là-dessus

quoiqu’il en soit, j’aurais vraiment aimé avoir un Revo mature, rapide et fonctionnel, babel intégré (le multilinguisme me semble tellement un besoin évident) pour le site que je dois attaquer dans les jours prochain, tant pis, ce sera peut-être pour le suivant celui-là est parti pour Evo + YAMS

bonne journée à toi
Have swing

Ah ben je ne peux pas vous en vouloir, ce n’est pas mon sujet à la base non plus je n’ai fait que l’emprunter, j’espère que son auteur aura eu sa réponse grace à nos discussions d’ailleurs.
Je suis trèèès loin de vos niveaux encore, je ne manipule pas de JS, je farfouille du PHP tout juste, j’aurai même encore du mal à utiliser les libs jQuery pour le moment, mais ça viendra peut être. Je patauge encore avec votre vocabulaire ^_^

Juste pour répondre à propos de Revo 2.1, je suis ravi que ça se soit encore amélioré (ils avaient appliqué un joli correctif pour les perfs aussi niveau backend sur une version tout réçemment), j’attends quand même qu’il sorte en finale, je ne suis pas encore prêt à affronter les petits problèmes parce que je ne saurais pas si ça vient du système ou de mon code, et puis je suis déjà presque en prod (bon c’est un site perso, rien à voir avec des développements pour des clients Pro)

(J’ai fait un test sur Webwait j’ai quand même 2s de chargement de la page d’accueil en moyenne sur 5 affichages et sans vider le cache )

@virtualgadjo : pour revenir sur ExtJS et l’infinie bontée des devs de MODX (comment ça ça sonne un peu trop « fanatique » ?), rien n’oblige l’utilisation de la librairie. Libre à toi d’utiliser Mootools pour tes interfaces back-end (en revanche, quid des conflits potentiels…)

Quote from: virtualgadjo at Apr 25, 2011, 02:48 PM

là où je te suis moins c’est pour l’install des modules sur Evo, je ne vois pas où est la bidouille.
Quand j’écris un module perso, je le fais intégralement dans son dossier, je fais un appel à la page index du module

include MODX_BASE_PATH."assets/modules/mp3s/index.php";

dans le gestionnaire, et hop le module est fonctionnel !

Il est vrai que sous Revo, il y a une étape supplémentaire. Une fois core/components/monExtra/index.php créé, il faut l’inclure dans les actions (ce qui remplace ton include MODX_BASE_PATH…), puis il faut ajouter cette « action » dans le menu des composants.

et hop le module est fonctionnel !

(… et il peut profiter de la gestion des droits, l’internationnalisation).

Mais je comprend très bien que « changer de workflow » peut être perturbant.

@Epy : il est vrai que Revo nécessite peut être plus d’optimisations (le prix d’une liberté accrue ?). Opengeek recommande de mettre en cache un maximum d’éléments. Par expérience, je sais que les TVs (variables de modèles) sont souvent la cause des lenteurs, ainsi que les appels de snippets non optimisés (par exemple garder le &depth=`10` par défaut de getResources).
Si te conseillerais de jetter un coup d’oeil à getCache, mais surtout à Executioner, qui te permettra de trouver le snippet/chunk ralentissant ta page.

Merci pour les infos ! je vais regarder ça de près

Salut,

sorry pas là hier...

@Romain, ça m’intéresse ce que tu me dis sur l’install des modules, j’avais suivi ça
http://rtfm.modx.com/display/revolution20/Custom+Manager+Pages
et, honnêtement, j’avais trouvé ça un poil lourd pour installer par ex mon éternel cropper d’images

Mais bon, ton enthousiasme Revolutionnaire donne envie de s’y remettre, vivement que la 2.1 sorte en stable je pense que je vais rejouer avec...

@Epy, fais juste attention à un truc, la lenteur à livrer une page est aussi fonction du serveur sur lequel est ton site, on ne peut pas tout mettre sur le dos de Revo (ça-y-est, Romain m’a contaminé )
Perso, j’ai des sites hébergés un peu partout (je teste beaucoup les hébergeurs pour mes clients et, d’ailleurs, balade mon site perso à travers le monde ) et, un site chez Sivit ou Inmotion n’est pas livré à la même vitesse pour le même site, même cms, même tout -> 10 fois plus rapide chez Sivit...
Ce qui reste mystérieux pour moi c’est la lenteur d’exécution de js la page une fois livrée, là aussi, même page exactement, même js, mêmes images même css, etc et je ne sais pas ce qui tourne (tournait ?) en tâche de fond sur Revo mais la différence était flagrante, rédhibitoire même, y compris en local ! J’ai hâte de voir si ça a changé auquel cas, Revo, peut-être

Have swing

Salut,

Je suis de bonne humeur ce matin, du coup voici un petit screencast « sans parole » qui, je l’espère, te convaincra de la facilité d’installation d’un extra (et je n’aborde même pas la possibilité de développer en dehors de la racine de MODX et d’utiliser un système de versioning)

http://modx-lab.com/cmp-setup.mp4

Bonne (swingy) journée

Hello Romain,

thanks pour le screencast, j’ai déjà fait le procédure une paire de fois (en fait, la première chose que je fais avec un cms est de voir comment je peux installer un module perso ou whatever le cms appelle ça, si c’est une usine à gaz, suivant...) et, effectivement, ce n’est pas démesurément insolvable
j’imagine même que quand tu le fais 3/4 fois ça devient un automatisme.
Soyons honnête, ça reste un peu plus "complexe" que l’install du même module dans Evo (module que par convention on met dans module mais qui pourrait être n’importe où, Evo aussi permet de développer hors sa racine) mais d’après ce que j’ai compris, on profite un peu plus des capacités de MODx lui-même dans son module

comme je le disais, vivement que la 2.1 soit stable, je vais rejouer un peu avec. De toute façon, le pli de MODx est clairement de tendre vers Revo, il doit bien y avoir une raison...

bonne journée à toi et, oeuf corse

Have swing
(tu connais forcément le titre du Duke "it don’t mean a thing if I ain’t got that swing", ceci explique cela )