[Résolu]Création dynamique des propriétés?

[lamba]

Bonjour,

Je veux ajouter de nouvelle propriétés à un contenu sous Alfresco, mais sans lui attribuer un custom type ou lui associer un aspect.
Ma question: est-il possible de le faire d'une façon dynamique avec du code java pour ne pas avoir de contrainte sur le nombre/type de propriétés à ajouter  :?:

Merci d'avance.

[rguinot]

qu'entendez vous par "dynamique" ? l'ajout de propriété doit il être déclenché sur évenement ? l'ajout de propriétés se fait habituellement par une implémentation d'onAddAspect ou autre… mais vous pouvez binder du code java que vous voulez sur un grand nombre d'évènements (voir les classes *ServicePolicies)

je ne vois pas de quelle contrainte de nombre vous parlez. d'autre part les policies en question peuvent déclencher du code javascript, pas uniquement du code java.

[lamba]

Merci rguinot pour votre réponse.

La contrainte que j'ai est que, je ne peux déterminer le nombre/type de propriétés à ajouter qu'au moment de la création du "Stub" et donc je ne peux pas définir un modèle à l'avance et l'appliquer au "Stub" au moment de sa création à moin qu'il y'a une possibilité de créer un modèle de donnée avec l'API Java.

J'espère que c'est mieux expliqué.


Merci.

[rguinot]

pourquoi ne pas ajouter vos propriétés au moment de la création de votre stub ? via des appels a nodeService.setProperty. ou alors je ne comprends pas le besoin

[lamba]

Rguinot, le nodeService.setProperty permet d'affecter une valeur à une propriété existante chez un document et pas de créer la propriété pour ce document.

Vous voyez ce que je veux dire?


Merci.

[rivarola]

La méthode setProperty permet bien de créer une propriété sur un noeud. A ma connaissance, si le QName de cette propriété n'est pas connu du ContentModel, la valeur sera quand même prise en compte. On arrive donc à créer à la volée des propriétés sur des noeuds et le repository vit bien avec. Par contre les valeurs qui ne sont pas des chaînes de caractères sont très mal gérées quand le noeud quitte son "store" d'origine. Par exemple un export puis ré-import ACP ne fonctionnera pas forcément bien, de même qu'une restauration depuis la poubelle, etc.

[rguinot]

en effet, on peut faire des :

nodeService.setProperty(content, QName.createQName("fake", "junk"), "dummy");‍

mais si fake:junk n'est définie dans aucun modèle.
mais comme le dit philippe, ce n'est pas propre et généralement une bonne pratique, notamment pour la gestion de types de données, de son indexation, etc …

[rivarola]

Je n'ai pas dit que c'était propre 😉
J'avais imaginé à une époque dédier un namespace aux propriétés dynamiques et modifier le DictionaryService pour qu'il "connaisse" toutes les propriétés bidon qu'on lui demanderait dans ce namespace. Il pourrait par exemple retourner une PropertyDefinition dont le data type dépend d'une convention de nommage… Mais ça fait beaucoup de boulot et au final je ne suis pas sûr que ce soit plus stable.

[lamba]

Résolu

Merci rivarola & rguinot.

En fait, je ne savais pas qu'elle permet la création aussi.