Question existentielle
Foloex
Member
Depuis que j'ai mis les doigts dans le code de PluXml, je suis vraiment impressionné par la qualité de l'ensemble. J'ai essayé d'imaginer les différentes choses qu'on peut faire avec. Après une longue réflexion, je me suis posé la question: qu'elle est l'essence de PluXml ? Est ce que c'est un moteur de blog ? de CMS ? Des deux ?
Finalement, je pense que PluXml est tout simplement un moteur de site web extensible via des plugins. Le coeur du système repose sur un moteur capable d'interagir avec du Xml et d'appeler des plugins. Du coup je me demande si PluXml n'est pas "impur". Dans le sens, que certaines parties du moteur sont mélangées avec ce que je considère comme des plugins.
Prenons par exemple de la gestion des médias, je ne suis pas sûr qu'il soit utile qu'elle fasse parti du moteur même. Je pense que l'ensemble gagnerait à bien séparer les plugins du moteur même. Cela permettrait de faire évoluer plus facilement l'ensemble. De plus, des développeurs tiers pourraient proposer leur alternatives à ces plugins officiels.
Imaginons que quelqu'un n'aime pas la gestion des Médias telle quel et décide de coder son propre plugin de gestion des Médias. Je suppose qu'actuellement il aurait la possibilité de court-circuiter les appels à Médias pour appeler son propre plugins. Le problème c'est que Médias est intégré en dur dans le moteur, ses paramètres sont mélangés avec ceux du moteur. Cela pose d'ailleurs des problèmes de sémantique importants. Par exemple, les paramètres de Médias se retrouve à la fois dans "Option d'affichage" et dans "Configuration Avancé", ce que je trouve un peu perturbant.
De mêmes, les commentaires sont pour moi aussi un plugin. Ils sont d'ailleurs désactivables comme un plugin.
Selon moi il faudrait écarter tout ce code du moteur pour le mettre dans des plugins. Après que ces plugins soient proposés avec la release de PluXml, directement activés, ne me dérange pas. L'avantage de procédé de la sorte permet d'avoir, d'une part, un noyau robuste, extensible, plus facile à faire évoluer, plus cohérent, et de l'autre, des plugins qui peuvent évoluer à des rythmes différents.
Voilà une liste non exhaustive de ce que je considère comme ne faisant pas partie du moteur de PluXml et qui devrait du coup être des plugins:
- les médias
- les commentaires
- les utilisateurs
- les articles
- les catégories
- les pages statiques
Bon je suis peut être extrême/idéaliste dans mes propositions
Qu'en pensez-vous ?
Finalement, je pense que PluXml est tout simplement un moteur de site web extensible via des plugins. Le coeur du système repose sur un moteur capable d'interagir avec du Xml et d'appeler des plugins. Du coup je me demande si PluXml n'est pas "impur". Dans le sens, que certaines parties du moteur sont mélangées avec ce que je considère comme des plugins.
Prenons par exemple de la gestion des médias, je ne suis pas sûr qu'il soit utile qu'elle fasse parti du moteur même. Je pense que l'ensemble gagnerait à bien séparer les plugins du moteur même. Cela permettrait de faire évoluer plus facilement l'ensemble. De plus, des développeurs tiers pourraient proposer leur alternatives à ces plugins officiels.
Imaginons que quelqu'un n'aime pas la gestion des Médias telle quel et décide de coder son propre plugin de gestion des Médias. Je suppose qu'actuellement il aurait la possibilité de court-circuiter les appels à Médias pour appeler son propre plugins. Le problème c'est que Médias est intégré en dur dans le moteur, ses paramètres sont mélangés avec ceux du moteur. Cela pose d'ailleurs des problèmes de sémantique importants. Par exemple, les paramètres de Médias se retrouve à la fois dans "Option d'affichage" et dans "Configuration Avancé", ce que je trouve un peu perturbant.
De mêmes, les commentaires sont pour moi aussi un plugin. Ils sont d'ailleurs désactivables comme un plugin.
Selon moi il faudrait écarter tout ce code du moteur pour le mettre dans des plugins. Après que ces plugins soient proposés avec la release de PluXml, directement activés, ne me dérange pas. L'avantage de procédé de la sorte permet d'avoir, d'une part, un noyau robuste, extensible, plus facile à faire évoluer, plus cohérent, et de l'autre, des plugins qui peuvent évoluer à des rythmes différents.
Voilà une liste non exhaustive de ce que je considère comme ne faisant pas partie du moteur de PluXml et qui devrait du coup être des plugins:
- les médias
- les commentaires
- les utilisateurs
- les articles
- les catégories
- les pages statiques
Bon je suis peut être extrême/idéaliste dans mes propositions
Qu'en pensez-vous ?
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
- les commentaires: PluXml est un moteur de blog donc les commentaires sont indispensable non (pas de forum)?
- les articles: idem indispensable à un moteur de site /blog.
- les catégories: si créations d'articles devient indispensable aussi
- les pages statiques: indispensable à un site web.
Après je ne suis pas d'accord, les pages statiques ne sont pas indispensable non plus.
Imaginons que je veuille créé un wiki à partir de PluXml, dans ce cas là je n'ai pas forcément besoin des "articles" tel qu'ils existent aujourd'hui. Je prendrais cet hypothétique plugin "articles" que je modifierais comme il faut pour faire un wiki. Alors qu'actuellement il faut que j'aille taper dans le code du moteur à la recherche des fonctions propres aux articles et que je modifie le code.
D'une part c'est plus compliqué, de l'autre c'est pas très réutilisable.
Après si on veut utiliser PluXml comme un blog on peut imaginer une archive de plugins qui vont bien pour faire un blog. Une autre pour faire un forum. Encore une autre pour faire un wiki.
Après on peut imaginer les trois qui tournent dans des onglets séparés (un peu comme sur ce site) mais qui utilise le même moteur: PluXml.
Ce que tu décris s'appelle un framework.
Tu as raison sur le fond et la forme si on résonne framework.
Mais ce n'est pas la vocation de PluXml d'être un framework, qui à la base est un moteur de blog, qui a évolué avec le temps pour répondre à certains besoins spécifiques et se rapprocher du modèle CMS.
Il restera donc avec en natif les fonctionnalités qui répondent au besoin de surement plus de 95% de ses utilisateurs.
Consultant PluXml
Ancien responsable du projet (2010 à 2018)
J'avoue être un peu déçu, j'ai l'impression qu'il n'y a qu'un pas à faire pour passer du moteur de blog option CMS à un framework. Certes ce pas risque d'être très grand
Il me semble qu'il serait bon de le mettre en plugin. Pourquoi pas ?
En effet, il y a bien des éditeurs WYSIWYG en plugin qui viennent greffer leur gestionnaire de média. Pourquoi ne pas laisser cette partie aux plugins et revenir sur une partie rédaction d'article avec juste du code, et avec option d'activer la toolbar Pluxml qui apporte la gestion des médias ?
Non ?
De plus dernièrement il y a eu un post sur l'impact des plugins sur les performances et il me semble avoir lu que ce n'était pas innocent à gérer un plugin donc passer les fonctions blog/cms en plugins aurait forcement un impact bien trop important sur les performances.
J'ai un string de l'array
Si j'ai choisi ce CMS, c'est pour sa simplicité et sa rapidité. Bien sure, PluXML devra s'enrichir de nouvelles fonctionnalités, sans entrer dans le concept usine à gaz. Les plugins sont une bonne choses, mais je pense qu'en mettre 10 sur son installation risque d’alourdir ce CMS. De même pour les thèmes : un thème kéger et c'est que du bonheur!
PluXml est et doit rester un outil simple pour les non "geeks" que vous êtes
Consultant PluXml
Ancien responsable du projet (2010 à 2018)
J'ai un string de l'array
Sinon, pour le fait que ça soit plus compliquer à utiliser (notamment pour les non informaticiens) sous forme de framework + plugins que dans la forme actuelle, je ne suis pas d'accord. Je ne vois pas en quoi c'est plus compliqué d'aller dans "plugins -> Médias -> configuration" au lieu de "Paramètre -> Paramètres d'Affichage" puis "Paramètres -> Paramètres Avancés" pour changer les settings de Médias. Au moins ça fait des unités logiques.
Mon avancement dans le découpage de PluXml est visible/récupérable à l'adresse: http://remisoft.ath.cx/gitweb/?p=pluxml/.git;a=summary
Côté dev, PluXml ou WordPress, c'est 50-50. Le code c'est de la poésie (pour reprendre le slogan de WP) pour les deux. PluXml offre moins de fonctions ce qui peut donner l'impression d'être plus facile à maîtriser alors que WP offre une personnalisation...... infinie. La preuve, avec WP, on peut refaire Imdb, un système de support par ticket, un site e-commerce ou encore un forum (si si je vous jure). Actuellement, il est difficile pour moi d'imaginer PluXml capable de faire tout ça. Comme je l'ai dit sur mon blog, PluXml c'est d'abord un moteur de blog qui va à l'essentiel. Il fait (que) du blogging et il le fait bien, très bien même. Le détourner en CMS demande déjà plus d'adaptation : détourner le champ chapô, détourner les champs meta, etc. Et je pense que WordPress est dans ce cas plus pratique (custom post type ça aide bien). Mais dans les deux cas, il faut accepter de mettre la main au code.
flipflip, niveau gros projet, je suis d'accord avec Jos, non pas par manque de fonctionnalité, mais à cause des limites imposées par l'utilisation de l'XML comme base de données. XML c'est joli, mais ça reste très chiant à étendre les fonctionnalités. La preuve, on est bien bloqué avec la gestion des médias, de gros problèmes pour ajouter un champ dans les commentaires, etc. De plus, si le blog commence à grossir, genre atteindre une taille de 50'000 articles, 10 pages statiques, 60'000 commentaires, etc.... l'accès au disque deviendra tellement lourd et long que PluXml (ou le serveur) génèrera une erreur je pense. Gros projet avec PluXml, c'est non.
En résumé : PluXml vise une utilisation précise, il le fait à merveille. Ne demandez pas trop
Pour le côté fw, pourquoi pas, ça me semble pas mal de pouvoir choisir vraiment toutes les fonctionnalités qu'on a besoin un peu comme Drupal.
L'objectif de PluXml n'est pas d'en faire un Wordpress.
1) Les choix techniques ne le permettent pas (utilisation du xml, pas de base de données)
2) Nous ne voulons pas que PluXml fasse du wiki, du forum, et j'en passe. C'est un choix que nous avons fait: juste un moteur de blog proche du CMS car personnalisation facile avec des plugins.
3) PluXml est fait pour des sites persos, pour des sites vitrines d'entreprise. Si vous en voulez plus, il faut vous tourner vers d'autres plateformes (Drupal, Wordpress, etc...)
Nous garderons cette orientation.
Si vous voulez utilisez PluXml comme un Wordpress, faites vous plaisir, mais nous n'irons pas dans ce sens.
Consultant PluXml
Ancien responsable du projet (2010 à 2018)
On travaille à ce qu'il devienne justement plus accessible.
Consultant PluXml
Ancien responsable du projet (2010 à 2018)
Je ne vois pas pourquoi il est inclus quand l'éditeur est en plugin... Mais ce n'est que mon avis et c'est la seule chose à mes yeux qui mériterait d'être optionnelle
Consultant PluXml
Ancien responsable du projet (2010 à 2018)
ya peut-être des plugins qui offrent ces fonctionnalités mais pour une plus petite échelle ... ?
j'dis ça, j'dis rien, hein