Il n'y a pas de façon standard de faire ce que vous voulez. L'API JCR ne permet tout simplement pas de stocker des valeurs Object arbitraires. Les seuls types de propriété valides dans JCR 1.0 sont:
STRING
BINARY
LONG
DOUBLE
DATE
BOOLEAN
NAME
PATH
REFERENCE
Tous ces types de propriété sont valides dans JCR 2.0, mais il y a plusieurs nouveaux:
WEAKREFERENCE
URI
DECIMAL
De plus, le javax.jcr.ValueFactory
n'a aucune méthode qui crée un Value
à partir d'un java.lang.Object
arbitraire.
Il y a trois options:
- Utilisez le type de propriété STRING et convertir votre valeur ENUM à l'aide d'une chaîne 'toString()'; ou
- Utilisez le type de propriété LONG et convertissez votre valeur d'énumération en une valeur intégrale en utilisant 'ordinal()' et en tant que longueur; ou
- Utilisez le type de propriété BINARY et convertir votre valeur ENUM à une valeur BINARY
OMI, l'option 1 est le plus logique. L'option 2 peut être meilleure dans certaines situations - par exemple, cela permettrait d'utiliser des opérateurs de comparaison sur votre propriété dans JCR-SQL et JCR-SQL2. L'option 3 fonctionnerait, mais ce n'est pas très pratique du tout.
Les options 1 et 2 peuvent également tirer parti des contraintes de type de nœud. Comme vous le savez, les définitions de type de noeud incluent les définitions de propriété et les définitions de noeud enfant autorisées par ce type de noeud, et l'une des définitions de propriété peut spécifier les valeurs autorisées à l'aide de contraintes. Les contraintes peuvent, par exemple, limiter les valeurs de propriété autorisées par des caractères génériques ou des valeurs littérales (pour les propriétés STRING et PATH), des plages de valeurs (pour les propriétés LONG, DOUBLE et DATE), des plages de longueurs (pour BINARY) Propriétés REFERENCE et WEAKREFERENCE), littéraux (pour les propriétés NAME). Notez qu'une valeur est considérée comme valide tant qu'elle est autorisée par toute contrainte. Par conséquent, pour l'option 1 ou 2, la définition de propriété décrivant une énumération peut utiliser des contraintes pour limiter les valeurs autorisées. Dans le cas de l'option 1, les valeurs littérales STRING d'énumérations limiteraient les valeurs autorisées définies sur la propriété. Voici un exemple simple en utilisant la notation CND de JCR 2.0:
[ex: foo] mixin
- ex: bar (STRING) < 'VALUE1', 'VALUE2', 'VALUE3'
Avec l'option 2, une plage (ou un ensemble de plages) avec les valeurs LONG acceptables fonctionnerait. Voici un exemple simple:
[ex: foo] mixin
- ex: bar (STRING) < [0,3)
Merci pour la réponse exhaustive. Je voulais éviter de comparer des chaînes, puisque j'ai un type de nœud qui est une énumération. L'utilisation du type de propriété String permettrait d'utiliser des valeurs autres que celles définies dans l'énumération, ce qui serait une erreur. Je l'ai déjà implémenté avec l'option 1., mais j'espérais qu'il y aurait un meilleur moyen :) – Simeon
Utilisez-vous un type de noeud pour définir la propriété? Si c'est le cas, vous pouvez limiter les valeurs en utilisant des contraintes. Par exemple, voici un mixin qui définit une propriété 'ex: bar' de type STRING qui n'autorise que 3 valeurs (désolé pour le formatage): [ex: foo] mixin - ex: bar (STRING) <'VALUE1' , 'VALUE2', 'VALUE3' –
Merci! C'est génial :) Je ne peux toujours pas partager les constantes entre la définition de la propriété et le code, mais c'est quand même mieux que juste des chaînes. Pourriez-vous ajouter cela à votre réponse pour plus de visibilité? – Simeon