Fragment de configuration WYSIWYG
Bonjour,
J'ai créé un fragment de configuration WYSIWYG sur JPlatform10, et tel que c'est indiqué dans la documentation il faut déclarer ce fragment avec une propriété du style :
wysiwyg.fragment.configuration.nomdufragment: cheminverslefichier/configuration-nomdufragment.conf

Bonjour,
Votre approche est bonne, et je viens de la vérifier en l'appliquant sur les sources récupérées du module de démo disponible sur GitHub :
1) Déclaration du fragment dans WEB-INF/plugins/DemoWysiwygPlugin/properties/plugin.prop
:
########################################################################
# Demo of a fragment declaration,
# it can be used in any configuration using :
# ::include{'property': 'wysiwyg.fragment.configuration.customfragment'}
#
wysiwyg.fragment.configuration.customfragment: /WEB-INF/plugins/DemoWysiwygPlugin/wysiwyg/fragments/configuration-customfragment.conf
2) Développement du fragment, dans le fichier WEB-INF/plugins/DemoWysiwygPlugin/wysiwyg/fragments/configuration-customfragment.conf
.
branding: true
3) Ajout de l'inclusion du fragment dans le fichier WEB-INF/jalios/wysiwyg/configuration-light.conf
(attention, modifier directement ce fichier n'est pas une bonne pratique, je voulais aller à l'essentiel pour valider le comportement d'inclusion de fragment)
{
'light': {
[...]
::include{'property': 'wysiwyg.fragment.configuration.codesample'},
::include{'property': 'wysiwyg.fragment.configuration.customfragment'}
}
}
4) Démarrage de la webapp, et vérification du résultat
- dans le fichier généré
js/jalios/core/wysiwyg/jalios-wysiwyg-configurations.js
- dans l'interface, en éditant un nouvel article, ou le branding est désormais visible pour l'éditeur light, mais pas pour le default.
Il doit y avoir une autre raison qui provoque l'erreur dans votre intégration.
D'accord, merci.
Dans ce cas est-ce que l'ordre de chargement des modules pourrait avoir une influence ?
Voici mon exemple : J'ai un module "outil" qu'on utilise sur plusieurs webapps. L'idée était donc d'y mettre le fragment de configuration afin qu'un autre module, cette fois-ci différent dans chaque webapp, fasse appel au fragment au moment de la définition de la configuration wysiwyg de la webapp courante.
On se retrouve donc avec 2 plugins.prop. Si celui de la config passe avant celui du fragment, cela peut-il poser un problème (il me semble que le custom.prop intervient tout à la fin) ?
D'après votre remarque , il faudrait que le module "différent dans chaque webapp" dépende du module "outil", i.e. que le plugin.xml
du premier déclare le second, dans une balise dependency
.
Est-ce bien le cas ?
Ah, ma réponse et votre dernier commentaire se sont croisés.
Super que le problème soit résolu ! ?