[CalendarPlugin] Indication inapplicable si on doit modifier des propriétés des champs standard des CalendarEvent dans le type hérité
Avec la version la plus récente (10SP2), si on applique l'indication 2 dans la FAQ du module Calendar (5.1), les classes générées ne compilent plus (signatures différentes dans le code à cause de la généricité, mais identique après compilation).
JDP ne démarre plus par conséquent.
[EDIT] Titre modifié, voir le détail dans les remarques
Bonjour Benoit,
Je ne comprends pas bien ton problème.
Voici ce que j'ai fait avec l'exemple donné dans la FAQ (et qui démarre correctement au passage, (Work On My Computer) ) :
unzip ~/Téléchargements/JPlatform\ 10\ SP2.war
unzip ~/Téléchargements/CalendarPlugin_5.1.zip
cd ./WEB-INF/data/types/
mkdir TestEvent
vi TestEvent/TestEvent.xml
./bin/catalina.sh run
Bonsoir Ludovic,
J'ai refais la même opération que toi et effectivement, ça passe.
En faisant un diff avec mon cas de figure, qui plante, j'ai identifié que la différence qui faisait planter est que les champs étaient surchargés dans la définition du type.
Cela vient du fait que dans des anciennes versions du module (mais je vais pas faire une recherche archéologique pour trouver le pivot), c'était la manière de faire : il fallait étendre AbstractMeetingCalendarEvent, et définir les champs. Maintenant il faut étendre l'implémentation (generated.CalendarEvent).
Et donc auparavant, il fallait mettre les définitions des champs (en respectant exactement les types et noms Java des champs définis).
Maintenant, cela n'est plus nécessaire, ni faisable dans certain cas.
Bon ... dans le cas qui m'interesse, il n'y avait rien de spécifique dans les (attributs des) champs qui empêchaient de compiler, donc mon problème immédiat est résolu.
Benoît
Merci pour l'info et à bientôt.
En fait c'est beaucoup plus contraignant que ça.
Si on applique effectivement l'indication telle quelle, alors ça oblige à insérer, comme dans l'exemple :
<fields>
<field type="super" />
</fields>Sinon l'édition des types hérités plante avec des NPE, parce que le EditCalendarEventHandler utilise des TypeFieldEntry pour les champs :
- sendEventUpdateMail
- freeSignUp
et si (ce qui est le cas) ces champs nous sont indifférents, qu'ils sont optionnels, avec une valeur par défaut, on ne peut pas les surcharger en mettant hidden="true", parce que sinon on a les problèmes de compilation sur l'entité dont je parle au dessus (signature différente en raison des génériques, mais identique après le "type erasure").
Deux solutions :
- soit on insère globalement les options des champs de CalendarEvent, quitte à perdre ses options spécifiques (ce que les clients ne sont jamais prêts à faire, c'est une régression)
- soit on créé une spécialisation de EditCalendarEventHandler (et donc on n'applique pas scrupuleusement l'indication) pour que les invocations aux TypeFieldsEntry qui posent problème ne se fasse pas.
Si on choisit la seconde solution, voici la partie à surcharger :
@Override
public boolean getAvailableFreeSignUp() {
if ((this.theContent != null) && (isFieldMissing("freeSignUp"))) {
return this.theContent.getFreeSignUp();
}
if (isFieldMissing("freeSignUp")) {
TypeFieldEntry localTypeFieldEntry = channel.getTypeFieldEntry(CalendarEvent.class, "freeSignUp", true);
this.freeSignUp = channel.getBooleanProperty("jcmsplugin.calendar.defaultValue-freeSignUp",
Boolean.parseBoolean(localTypeFieldEntry.getDefaultValue()));
}
return this.freeSignUp;
}
@Override
public boolean getAvailableSendEventUpdateMail() {
if ((this.theContent != null) && (isFieldMissing("sendEventUpdateMail"))) {
return this.theContent.getSendEventUpdateMail();
}
if (isFieldMissing("sendEventUpdateMail")) {
TypeFieldEntry localTypeFieldEntry = channel.getTypeFieldEntry(CalendarEvent.class, "sendEventUpdateMail",
true);
this.sendEventUpdateMail = channel.getBooleanProperty(
"jcmsplugin.calendar.defaultValue-sendEventUpdateByEmail",
Boolean.parseBoolean(localTypeFieldEntry.getDefaultValue()));
}
return this.sendEventUpdateMail;
}
Statuts
