mon (in)expérience Joomla

**sharky** · 04/08/2011, 05h22

Re : mon (in)expérience Joomla

Salut,

J'aime bien ton texte!!

Tu as bien résumé la communauté !! La personne qui a développer AllEvent est partie un peu comme toi. Elle avait besoin de besoins spécifique qu'elle n'a pas trouvé, donc elle a créé son extension et partagé.

J'espère, que peut-être, que la tienne ce trouvera sur la JED un jour

Joomla 1.6/1.7 n'a que 7 mois. Souvent les développeurs d'extensions n'ont pas encore eu le temps de les migrer. Car, encore comme toi, la plupart le font bénévolement (je parle de la plupart des extensions gratuite)

Ensuite, je ne connais pas tes besoins concernant les événements et pourquoi ton choix c'est porté sur Allevents, mais peut-être qu'une autre extension 1.6/1.7 aurait fait aussi l'affaire!

http://extensions.joomla.org/extensions/calendars-a-events

Mais j'ai bien aimé ton texte, qui donne bien l'exemple des problèmes que l'on peut rencontré avec Joomla combiné avec des extensions tierces et ces maintenances.
L'esprit communautaire est une force déroutante

Jusqu’où peut-on aller!

**cavo789** · 04/08/2011, 06h38

Re : mon (in)expérience Joomla

Bonjour

Comme tu le décrit si bien, dans la majorité des cas, chaque développeur d'extension travaille en solitaire. Contrairement au core team de Joomla où il y a une approche commune et une vision globale (qu'est-ce qui existe aujourd'hui, quelles sont les évolutions futures que l'on souhaite, ...), le développeur lambda essaie de prendre les bonnes décisions; en fonction de ses compétences, de son temps libre et de sa connaissance du monde Joomla.

Même bien informé, cela reste mission impossible. Déjà du fait que le développeur est solitaire : il a généralement son métier; son occupation professionnelle et sur le côté, il développe à ses heures perdues. Les journées n'étant pas extensibles; comme tu le décris si bien, il ne lui est pas possible de faire des passerelles vers les composants les plus réputés.

Je peux comprendre ton point de vue; je voudrais cependant le nuancer : le code source des extensions est ouvert; chacun y a accès. Plutôt que de vouloir créer sa propre extension from scratch (et participer encore plus à ce que tu décris); pourquoi ne pas prendre sur soi de développer l'interface souhaitée ? Dans ton cas, tu aimerais une passerelle vers un composant de newsletter. Pourquoi ne pas programmer cette intégration et faire évoluer du coup les deux composants (newsletter et agenda).

Ce que j'écris ci-dessus, tu le sais déjà, ton expérience (et pas ton inexpérience) t'ont déjà appris cela.

A titre perso, j'ai très apprécié tes apports concernant AllEvents. Ce serait avec un grand plaisir que je continuerais si d'aventures tu continuais le chemin avec AllEvents. J'engage des programmeurs; le salaire est payé en points de karma

> La personne qui a développer AllEvent est partie un peu comme toi.
>Elle avait besoin de besoins spécifique qu'elle n'a pas trouvé, donc elle a créé son extension et partagé.

C'est entièrement exact. Résultat des courses : je développe le composant depuis deux ans maintenant. 60.000 lignes de nouveau code. L'aurais-je fait si j'avais su ? Pas sûr... Suis-je heureux de l'avoir fait ? Oh que oui !

**alakauf** · 04/08/2011, 10h49

Re : mon (in)expérience Joomla

Bonjour,
en fait mon site va évoluer fréquemment. Par exemple, je prévois d'intégrer assez vite une fonctionnalité permettant le prêt de livres entre adhérents. Et j'espère par la suite pouvoir y intégrer encore d'autres fonctionnalités pour répondre aux besoins de mes adhérents.

Cela signifie que je vais devoir intégrer d'autres modules, au fur et à mesure que le site se développera. Dans l'absolu, un outil comme Joomla! et ses modules serait idéal. Sauf, que, comme la communication entre modules ne passe pas par le coeur, comme ce serait le cas dans une approche client-serveur, mais se fait directement entre modules (donc en étoile), cela signifie qu'il me faudra à chaque fois développer des plug-ins entre les modules dont j'ai besoin.

Autrement dit, non seulement je vais devoir apprendre Joomla! mais aussi chacun des modules. Ce que je considère comme une (petite) galère. De plus, j'aurai assez vite des problèmes de compatibilité lié au fait que j'utiliserai Joomla! 1.5 alors que les nouveaux modules pourraient n'être que pour 1.7.

C'est donc à cause de cela que j'en suis arrivé à la conclusion que la conception de mon site "par briques", dans la mesure où je devrai développer un "ciment différent" pour chacune, n'était pas viable pour mes besoins. Et donc que je m'oriente vers une option "je ne travaille qu'avec mes briques".

Je reconnais volontiers que faisant cela je reste dans le principe "que je dénonce". C'est d'ailleurs pour cela que je ne publierai jamais mes modules (désolé Sharky). Mais je ne veux pas non plus devoir passer "un temps excessif" pour ce qui n'est pas "ma spécialité", et, comme je le disais, je ne souhaite pas devenir un "gourou Joomla!".

Mon approche est purement "utilitariste": je dois avoir un site sous Joomla! pour bénéficier du template commun à l'association. Et en même temps je veux pouvoir faire évoluer mon site "de manière simple et rapide". En gros je veux fonctionner en mode "utilisateur avancée" et non "développeur".

**cavo789** · 04/08/2011, 10h56

Re : mon (in)expérience Joomla

Envoyé par alakauf Voir le message

Sauf, que, comme la communication entre modules ne passe pas par le coeur, comme ce serait le cas dans une approche client-serveur, mais se fait directement entre modules (donc en étoile)

Je ne visualise pas très bien.

Tu as un logiciel A et un logiciel B. B dispose de quelques tables dont p.e. les gestions des utilisateurs. A voudrait réutiliser la table des utilisateurs. Il faut donc que A apprenne à le faire ==> nécessité d'écrire un code (peu importe le nom (plugin, passerelle, bridge, ...).

Le logiciel C permet d'afficher des articles. A doit savoir comment sont architecturée les tables de C pour y ajouter ses propres infos.

Etc. Dans tous les cas, pour que deux logiciels puissent bénéficier des avantages de l'autre, il faut une passerelle.

La communication ne se fait pas vraiment au niveau des modules mais au niveau des tables; de la base de données.

Vois-tu une autre approche ?

**alakauf** · 04/08/2011, 12h04

Re : mon (in)expérience Joomla

Il y a plusieurs cas complémentaires. Une première approche serait "objet". je vais prendre le cas du gestionnaire d'événements. Pour moi, un événement géré par un module extérieur à Joomla!, devrait être un article (au sens Joomla!) dont la catégorie serait monmodule.evenement et qui serait enrichi par une date, un lieu, un système de réservation, etc. Le module de gestion d'événements aurait donc "juste" la tâche d'afficher les éléments spécifiques, en précisant à quel moment "l'article" doit être affiché dans le flux. A côté de cela, l'affichage de l'agenda est un "service" supplémentaire, qui définit une autre méthode d'affichage des articles.

Donc, un module soit offrirait une vraie extension d'une concept Joomla! (dans mon exemple l'article). Soit elle offrirait un service supplémentaire (ici l'affichage en agenda, sous réserve que les articles soient des événéments).

La structure des tables est donc alors totalement masquée. C'est purement de l'implémentation. Et il n'y a donc pas nécessité de communication directe entre modules. Soit j'utilise l'API "standard" sans savoir quel type d'objet il y a réellement derrière (c'est le boulot du coeur). Soit je dis, "je crée un module qui dépend de ..." et j'utilise alors les extensions spécifiques à ce module. Mais l'utilisateur sait qu'il faut alors installer un module supplémentaire pour pouvoir fonctionner.

De cette manière, un gestionnaire de lettre de diffusion sait qu'elle gère des articles. Quel est le type spécifique de l'article, elle s'en fiche, car elle va appeler une fonction display(). Et c'est le coeur, en fonction de la catégorie qui saura s'il faut appeler la fonction "standard" ou celle correspondant à un événement.

**cavo789** · 04/08/2011, 12h20

Re : mon (in)expérience Joomla

Cette approche (réutiliser la notion d'article) a été utilisée par, j'ai eu oui dire, FlexiContent, et c'est absolument certain que ce fût un excellent choix de développement. C'est que j'expliquais dans ma première réponse concernant les compétences du développeur : le type qui développe un composant doit déjà avoir un sacré niveau technique et une excellente connaissance du système (joomla en l'occurence).

Ensuite, est-ce une si bonne idée : si tout le monde utiliserait (sous J1.5) la table jos_com_content pour y stocker ses données, cela deviendrait vite un bordel; je pense. Quid si tu as des modules qui affiche la liste des derniers articles et qui ne sont pas prévus pour permettre de sélectionner une section précise ? Dans ce cas, le module va mélanger un article avec un évènement avec une marchandise, ... Cela risque d'avoir quelques effets de bord pas négligeable.

Cela serait très, fortement, contraignant je pense pour les développeurs occasionnels car, avant de développeur leur petit "composant à eux", ils vont devoir se taper une littérature à faire peur aux plus téméraires.

La vision que tu présentes ici nécessite un vrai changement de direction pour la toute grosse majorité des composants Joomla qui ont évolué au fûr et à mesure pour devenir des poids lourds (je pense p.e. à K2 puisqu'on parle d'articles).

C'est, à mon humble avis, une vision idéale mais utopiste. Cela donnerait un coup de frein important à toute cette collectivité de personnes qui développent pour le plaisir, qui ont commencé avec un petit truc; petit truc qui a grandit et qu'ils ont mis à disposition sur le net ("Si cela peut aider d'autres personnes; tant mieux").

Très sympa en tout cas comme discussion !

**didier l** · 04/08/2011, 12h28

Re : mon (in)expérience Joomla

Joomla! est un produit assez ouvert ...

Soit tu prends la version de base et tu fais un site web calssique

Soit tu veux aller plus loin, mais sans trop de risques, et tu choisis quelques extensions connues et reconnues

Soit tu veux aller encore plus loin, tu prends des extensions plus exotiques, tu crées tes propres extensions ...

A toi de voir ou tu mets le curseur et quelles sont tes réelles attentes ....

**chabi01** · 04/08/2011, 12h52

Re : mon (in)expérience Joomla

abonné à cette discussion passionnante de fond, les remarques faites ici sont judicieuses et vraies...
Cordialement,

**alakauf** · 04/08/2011, 15h15

Re : mon (in)expérience Joomla

Christophe, je ne suis pas tout à fait d'accord avec toi. D'après le peu de recherches que j'avais fait concernant Joomla! il y a eu "une vie avant le modèle MVC". Je pense que quand les développeurs du coeur ont dit "on passe en MVC" il y a du y avoir quelques grincements de dents, et que certains modules ne sont toujours pas MVC.

Or, cette approche MVC est déjà un pas vers ce que j'aurais aimé trouvé dans Joomla!. En effet, le découplage entre données, traitement et visualisation signifie que demain je peux modifier totalement ma structure (donc ma table) sans que les fonctionnalités ou la présentation ne soient impactés. Ce n'est donc ni plus ni moins que de l'encapsulation classique.

En revanche, avec des plug-ins qui vont directement lire des tables qui ne sont pas à moi, si demain le propriétaire des tables décide d'en changer totalement la structure, cela signifie que mon site foirera sans que sache pourquoi.

Maintenant, suppose que je te fournisse une classe Article, et que je te dise, voici son interface (add, delete, edit, show). Ne vous préoccupez pas de ce qu'il y a derrière. Si elle ne vous suffit pas en terme de contenu, vous pouvez l'enrichir par dérivation et donc écrire une fonction add() qui serait

Code:

parent::add('monmodule.montype', ...);
..puis la sauvegarde de mes ajouts...

Est-ce que cela te paraitra insurmontable de créer une classe Evenement qui dériverait de cette classe article, et qui se contenterait de gérer des tables additionnelles?

Maintenant, si je t'ajoutes, "votre objet est un agenda? Dans ce cas pourriez-vous le faire dériver de l'interface PhP que voici?". Car après tout, quelque soit le but d'un agenda, quelque soit sa présentation, on y retrouvera toujours plus ou moins les même fonctionnalités.

Et si maintenant je termine en te disant "votre besoin ne correspond pas à une fonctionnalité déjà imaginée? Dans ce cas, pourriez-vous créer une interface PhP qui serait l'interface source de tous les modules proposant ce type de fonctionnalité?".

Bien sur on pourrait créer un module sans cet interface type, et donc dire "mon module est un monde parallèle". Ou on peut dire "je crée l'interface pour devenir une extension de Joomla!".

Donc le nouveau développeur peut très bien créer son module "à l'ancienne", le proposer à la communauté, mais en sachant qu'il ne sera pas nécessaire utilisable "nativement" par les autres modules. Et le développeur aguerri, proposera son module avec une interface PHP de sorte qu'il soit utilisable de manière transparente par les autres modules.

J'ajouterai d'ailleurs que si demain Community Builder faire un CB2 en modifiant toutes ses tables, combien de sites Joomla! fonctionneront encore? Tout cela parce qu'il y aura eu un défaut d'encapsulation.

**jisse03** · 04/08/2011, 15h48

Re : mon (in)expérience Joomla

Bonjour,

Je rejoins cette discussion intéressante au possible

En effet, le découplage entre données, traitement et visualisation signifie que demain je peux modifier totalement ma structure (donc ma table) sans que les fonctionnalités ou la présentation ne soient impactés.

Pas mal de composants Joomla! ont déjà cette structure, et donc peuvent être étendus sans provoquer de catastrophes.
Les modules, qui eux ne servent qu'à présenter un sous-ensemble de données d'un composant, s'ils sont bien écrit, appellent la ou les classes model du composant pour requérir les données, ce qui reste également conforme, tant que l'API des classes model du composant ne sont pas changées d emanière incompatibles.
Pour les plugins, qui viennent soit étendre le système entier (plugins de type system) ou les plugins spécialisés, il en va de même, ils se greffent sur l'un des évènements du controleur du composant (onBeforeDisplay par exemple) pour retraiter les données en réalisant l'expansion des tags ou l'inclusion de tables tierces (plugins de recherche par exemple).

Où les choses se compliquent et où je rejoins Christophe ou garstud, c'est que si l'on voulait tout caser selon un modèle articles, on arriverait très vite à une monstrueuse pagaille, du même ordre que si l'on voulait caser le plan comptable, les écritures et les bilans dans une seule table d egestion. La dérivation est toujours préférable, ne serait-ce que pour permettre l'insertion et la suppression d ecomposants (les objets métiers) sans mettre en péril l'ensemble.

L'exemple le plus concret et réussi est par exemple Community Builder, qui s'appuie sur la table #__users de Joomla!, mais étend les fonctionalités par ses propres tables annexes, en permettant énormément de choses. CB s'étend de plus avec un nombre de plugins absolument effarant, tant pour lui apporter des gadgets que pour intégrer de nomberux composants (les articles de com_content, réutilisés par CB et son plugin CB Blogs, les boutiques Virtuemart ou Tienda, des composants de gestion vidéo, galeries, etc..). On peut décider d esupprimer Community Builder sans que ces autres composants cessent d efonctionner. Si CB étendait directement la table #__users, la problématique serait tout autre, en particulier de srisques énormes en cas de désinstallation du composant, ou si un autre composant (mettons eCommerce ou forum y greffait également ses champs).

La logique d'intégration par l'interface publique des composants reste la solution la plus avancée actuellement en termes de souplesse, tant qu eles extensions (composants, modules et plugins) respectent le modèle. Et il ets vrai qu'on trouve encore des composants ne respectant pas scrupuleusement le modèle MVC, et encore plus de modules en tous genres qui attaquent directement le stables d'un composant sans s'appuyer sur le model. Mais en ce cas, ce n'est pas la philosophie modulaire de Joomla! qui est à questionner, mais plutôt ces modules non respectueux du tout.

**alakauf** · 04/08/2011, 16h24

Re : mon (in)expérience Joomla

Au vu de ce dernier message, j'ai l'impression qu'il y a eu un moment une incompréhension. Bien sur il n'est pas question qu'une personne, sous prétexte qu'elle "étend la notion d'article", touche à la table Joomla! définissant les articles. Sinon, effectivement, bonjour la pagaille.

Par contre, si je reprends ce que je disais, et qui semble avoir été mal compris, c'est que, dans l'exemple de l'événement, un événement c'est un article + une date + un lieu + un système de réservation. Donc, pour moi il y a une partie de l'info dans la table "articles" et le reste dans des tables séparées.

Et qu'à partir de là, un module de création de lettre de diffusion aurait une fonction d'inclusion d'un article qui serait de la forme display(32) (si je veux inclure l'article numéro 32). Joomla!, identifiant via la catégorie de cet article que c'est en fait un événement (donc géré par le module evt), au lieu d'utiliser sa fonction display() d'article, utiliserait alors celle de evt.

Par là, le module de lettre de diffusion n'a pas besoin de savoir quels autres modules existent, ni à avoir de plug-ins pour discuter avec. Il se contenterait de savoir qu'il manipule des articles.

**didier l** · 04/08/2011, 19h16

Re : mon (in)expérience Joomla

Je crois (ou j'ose croire

) que la core Team garantit la pérennité du noyau de base.

Après, il faut s'assurer que chaque extension reste compatible avec le noyau. Même si la technique était plus complexe, il y avait déjà sur la version 1.5 la possibilité de modifer la structure initiale (on parlait de hack)

**jisse03** · 04/08/2011, 19h24

Re : mon (in)expérience Joomla

Après, il faut s'assurer que chaque extension reste compatible avec le noyau

Problème classique de tout système ouvert

un événement c'est un article + une date + un lieu + un système de réservation

Là, pas nécessairement. Un article est un contenu. Si tu mets une partie article lié à des extensions diverses, que se passera t-il le jour où tu désinstalles ce composant ?

Par là, le module de lettre de diffusion n'a pas besoin de savoir quels autres modules existent

Un composant newsletter ignorera les modules, mais respecte les composants installés. Prends par exemple Acymailing, la quasi référence absolue sous Joomla!, il y a des plugins pour une montagne de composants, permettant d'inclure un élément de tout composant pour lequel le plugin d'insertion existe.

Un système générique avec tout et presque n'importe quoi dans une même structure existe, au moins au niveau base de données, avec MongoDB. Mais cette approche pose d'autres problèmes, et extrêmement grave, genre comment retirer les références aux éléments supprimés.
Le Graal, où tout ou presque est abstrait est un idéal sur le papier, mais aucune implémentation pratique n'a jamais réussi à percer.

**jisse03** · 04/08/2011, 19h27

Re : mon (in)expérience Joomla

Je reviens sur un détail

le module de lettre de diffusion

Un module, sous Joomla! est une simple vue sur une partie du contenu d'un composant, ou une vue HTML sur un contenu quelconque.

Une vu n'est pas le contrôleur d'un objet métier, mais bien ce qui est indiqué, une fenêtre de visualisation d'un contenu.

Ce sont les composants Joomla! les vrais objets métier (contenu, eCommerce, forum, galeries...)

mon (in)expérience Joomla

mon (in)expérience Joomla

Commentaire

Commentaire

Commentaire

Commentaire

Commentaire

Commentaire

Commentaire

Commentaire

Commentaire

Commentaire

Commentaire

Commentaire

Commentaire

Commentaire

Annonce

Partenaire de l'association