We apologize for untranslated text, you can use the Google Translation button to get an automatic translation of the web page in the language of your choice.

A propos des types de données et du contrôle d'intégrité

Benoit Chapel · on 5/26/14 at 9:05 AM

Bonjour,

J'ai créé un type "Sharing" qui étend Publication dont le but est de stocker des couples de membres (2 attributs Member).

Ce type n'a pas été crée par l'interface d'admin de JCMS car ce type n'a pas besoin d'être géré par le backend, il est créé/supprimé par programmation.De plus, c'était "lourd" de le créer via l'interface puisqu'il fallait le créer manuellement sur différents serveurs (dev, préprod, prod ...)

J'ai remarqué que si on ne crée pas le type de publication par l'interface de JCMS, aucun StorableHandler n'a été créé automatiquement. Si JCMS est capable de s'en sortir par instrospection, il génére des avertissements dans les logs.

Pour éviter ces avertissements, j'ai écrit un Sharing_HANDLER qui implémente StorableHandler.

Ces deux classes sont référencées dans la balise <java-classes> de mon module.

Tout semble fonctionner.

 

Actuellement, dans le contrôle d'intégrite, j'observe une centaine de message :

Le type "Sharing" n'existe plus.

J'ai l'impression que j'ai une erreur par instance du type.

 

Est-ce que je peux créer des types de pubications par le code comme je l'ai fait ? Ai-je oublié de faire quelque chose ?

Est-ce que mon type est indéxé ?

Qu'est-ce que signifie l'erreur dans les contrôles d'intégrité ?

Est-ce que ces contrôles d'intégrité peuvent avoir un impact sur les performances ?

 

4 pts
Olivier Jaquemet · on 5/26/14 at 9:39 AM

Bonjour Benoit,

  • Vous pouvez tout à fait créer des types de publication par le code comme vous l'avez fait
  • Si vous faites cela, le StorableHandler doit être généré par un outil interne à JCMS (et regénéré dès que vous modifier votre classe) : 
    com.jalios.jstore.tools.jsc -d path/to/directory/containing/your/class/  fr.full.qualifier.name.of.YourClass

    Par exemple : 
    com.jalios.jstore.tools.jsc -d WEB-INF/classes/com/example/myplugin/model/  com.example.myplugin.model.FooBar

Le reste doit suivre correctement et sans erreur.

#6
  • Vous pouvez tout à fait créer le fichier XML à la main, tant que vous le placez au bon endroit (WEB-INF/data/types/MyType/MyType.xml)
    passer par l'interface est la meilleure approche pour garantir l'intégrité du fichier
  • Dans ce cas, la classe Java MyType.java et toutes les classes correspondante doivent être générée par JCMS, dans le package generated., ne référencez pas ces classes dans votre plugin. et n'utilisez pas des classes dans vos packages
  • Si vous souhaitez ajouter du code métier à cette classe, créer une classes abstraite dans votre package, et modifier le fichier XML pour qu'elle en dérive (action possible depuis l'interface)
  • Vous devez référencer ce type dans votre plugin pour qu'il soit inclus dans votre packaging et déployé sur les différentes instances

Je précise, sil était besoin, que la création d'un type de contenu est une opération de développement (raison pour laquelle l'éditeur de type contenu est dans la section développement, non accessible quand le site de production est correctement configuré) et que vous n'auriez de toute façon en aucun du faire cette opération manuellement sur chaque instance de production. C'est une opération à faire sur l'environnement de dév, puis à déployer sur la recette et la prod via les mécaniques de déploiement habituelles

Olivier Jaquemet · on 5/26/14 at 10:23 AM
#7

Ok, je vais le créer via l'interface comme cela il sera indexé.

Je suis d'accord que si on considère la création d'un type comme une opération de développement, cela n'est fait qu'une fois.

Cependant, je vous ferai remarquer qu'avec cette approche, si je distribue mon module à d'autres utilisateurs de JCMS, il faut leur dire de créer un type en développement, déployer le module en développement également et ensuite pousser en préprod et en prod. Le type est à créer en dév uniquement mais le module est à déployer sur chaque instances de chaque serveur. Vous conviendrez que pour une approche modulaire, elle n'est pas des plus pratique.

Benoit Chapel · on 5/26/14 at 10:36 AM
#8

Cette approche est tout à fait modulaire, mais il me semble que vous ne l'appliquer pas comme il faut :)

  • le développeur du module :
    • réalise cette opération de création de type sur son environnement de développement
    • référence le type dans le fichier xml du plugin
    • fourni le module pour déploiement
  • le responsable de la webapp
    • intégre le module en environnement de dev (soit via le SVN, soit via déploiement d'un livrable)
    • et la webapp est généré, déployé en recette, validée, puis déployé en prod

Et encore mieux, si vous utilisez JADE, tout ça est construit automatiquement à partir du SVN.
cf JADE - Plate forme d'intégration continue JCMS

Olivier Jaquemet · on 5/26/14 at 10:48 AM
0 pts
Benoit Chapel · on 5/26/14 at 11:05 AM

Pour un développement interne, ok sur le principe.

Cependant, quand je dis que ce n'est pas très modulaire, il me semble que vous ne comprenez pas ce que je veux dire :

Si un rectorat A développe un module M en suivant votre approche. Puisque le module M référence un type T qui n'est pas fourni par JCMS, le type T doit être créé préalabalement. Pour le rectorat A, en suivant votre procédure, il a créé son type T durant la phase de développement. On est OK.

Le rectorat A transmet son module M à un rectorat B qui a un JCMS. Puisque le type T référencé par le module M n'existe pas dans le JCMS du rectorat B. Si le rectorat B veut utiliser le module, il faudra qu'il crée le type T sur son serveur de dev, et qu'il installe le module M en dév, préprod, prod.

Lorsque le type T était intégré dans le module M (mais non accessible en BO et non indexé), il suffisait de fournir le module M au rectorat B qui n'avait pas besoin de passer par une phase de développement.

 

#1

Je ne comprends toujours pas votre point. Le type T est fourni dans le module, donc que ça soit pour une webapp X ou Y du rectorat A ou B, le type est bien là.

Olivier Jaquemet · on 5/26/14 at 11:09 AM
#2

Il y a peut être quelque chose qui m'échappe.

Prenons l'exemple de mon type Sharing.

Jusqu'à présent, comme je l'avais créé dans mon package fr.acclermont.Sharing, il était référencé dans la balise : <java-classes> <java class="fr.acclermont.jcms.plugins.sharedcalendar.Sharing_HANDLER" /> <java class="fr.acclermont.jcms.plugins.sharedcalendar.Sharing" /> <java class="fr.acclermont.jcms.plugins.sharedcalendar.SharingService" /> </java-classes> Le code Sharing.java était présent dans le jar inclus dans le zip du module.

Maintenant, si je retire mon Sharing existant et si je le crée via l'interface JCMS. J'aurai un generated.Sharing qui ne sera plus dans mon .jar du module. Je disais que le type generated.Sharing n'était pas présent dans mon module mais c'est peut être parce qu'il manque la référence que vous évoquez au post #6.

Qu'elle syntaxe utiliser dans ce cas pour référencer generated.Sharing dans mon module pour que mon module soit autonome ?

Un simple code comme : <types> <type name="Sharing" /> </types>

Est-ce que ça suffirait ?

Benoit Chapel · on 5/26/14 at 11:33 AM
#3

Effectivement, maintenant je comprends mieux votre problème.

Pour référencer un type généré vous devez mettre la balise suivante dans le fichier plugin.xml :

  <types>
    <type name="Sharing"/>
  </types>

La déclaration du type sera alors inclus dans le plugin et déployer avec ce dernier.
Aucun besoin de référencer les classes générés.

Et si vous avez modifier certains gabarits, il faut le préciser comme ceci :

  <types>
    <type name="Sharing"/>
      <file path="doSharingFullDisplay.jsp" />
      <file .../>
    </type>
  </types>

Olivier Jaquemet · on 5/26/14 at 11:39 AM
0 pts