Bonjour,
Dans spip-league\config, qu’est-ce qui est prévu comme mécanisme (surcharge de fichier, pipeline, etc.) pour pouvoir modifier le comportement d’une méthode d’une classe qui a le mot clé « final » ?
Il me semble précisement que si on met FINAL c’est pour éviter une surcharge… ca serait quel classe/méthode qui mériterait cela ?
Bonjour,
Aucun à ce jour pour les classes ; il faudra être un peu plus précis sur le besoin.
Si une classe à le mot clé final cela indique qu’elle n’a pas vocation à être étendue : et c’est plutôt une bonne pratique généralement (composition over inheritance).
Par conséquent,
- si c’est une classe publique pour un « service » spécifique, il faudra créer un décorateur et surcharger le service (en définissant une autre classe) via config/custom.php du site ou config/services.php d’un plugin et injecter dans le constructeur du décorateur la classe native.
- si c’est une classe interne il faudra ouvrir une discussion sur les besoins certainement pour en discuter
À vrai dire on n’a pas encore eu à regarder cela en détail encore, beaucoup de travail doit être fait encore sur cette version 5.
Quel est le besoin ?
Merci pour cette réponse.
Un plugin peut donc avoir un fichier config/services.php
Je viens de découvrir la documentation sur ce sujet :
Mon besoin est de rendre compatible avec SPIP 5, le plugin CIMS « Publication multi sites avec filtrage par rubrique » (cims : plugin « publication multi sites avec filtrage par rubrique » - SPIP-Contrib).
Ce plugin CIMS permet d’éviter des saisies en double dans les cas suivants :
- un site intranet dont une partie des informations seulement doit être accessible en extranet ;
- un site intranet et un site internet d’un même organisme avec des d’informations communes, mais également des informations propres à chaque site ;
- etc.
En particulier, il utilise une table « meta » par site (ex : spip_cims_meta_site1), afin que chaque site dispose de sa propre configuration, mais prend systématiquement dans la table spip_meta certaines clés (alea_ephemere, etc.).
J’ai élaboré une solution, qui fonctionne, en modifiant directement (pour le test uniquement car je ne souhaite surtout pas faire un fork) :
- la méthode publique repository de la classe ConfigManager de spip-league\config
- trois méthodes publiques (set, delete, refreshFromStore) de la classe ConfigEntries de spip-league\config
Si j’ai bien lu il s’agit maintenant de :
a) créer un décorateur : j’ai exploré cette piste et j’ai des éléments sur ce sujet.
b) injecter dans le constructeur du décorateur la classe native : c’est noté.
c) surcharger le service (en définissant une autre classe) via config/services.php d’un plugin : j’ai vu l’exemple de Configurer les services d’un plugin - SPIP 5.0 - Documentation technique ( $services->load(‹ SpipContrib\Plugin\MonPlugin\ ›, ‹ …/src/ ›) ) toutefois je souhaiterais en savoir davantage sur ce point.
Il te faudra attendre encore un peu. Comme te l’a dit marcimat, « Beaucoup de travail doit être fait encore sur cette version 5. »
C’est encore du dev, tout peut changer avant d’avoir un machin stabilisé.
Pour info, la classe ConfigEntries est @internal : elle ne fait pas partie de l’API et par conséquent, n’est prévu que pour un usage interne …
Tu fais donc ce que tu veux, mais pour ce qui sera de la maintenabilité de ta solution, nous n’offrons aucune garantie.