100 Content Management

Wedia est destinée à gérer de manière simple et cohérente l’ensemble de vos documents, textes et médias en vu d’être exploités dans différents canaux.

Cette section va détailler l’ensemble des fonctionnalités disponibles.

Entité d’objet

Principe fonctionnel

Un objet déclinable est représenté fonctionnellement comme une entité. Celle-ci est déclinable suivant trois critères : le groupe, le projet et la langue.

Lorsqu’un objet possède ses trois notions, on obtient le schéma de principe suivant :

On observe ici la même entité de ce contenu dans le groupe A qui est décliné de cette façon :

hors groupe

version anglaise
version française

projet 1

version japonaise
version anglaise

projet 2

version française
version anglaise

projet 3

version française
version anglaise

Conventions de nommage

En excluant les notions de projet layout-driven ou content-driven, on nommera les objets non-liés à un projet : contenus groupe.

Les versions de ce contenu dans un projet sont appelés déclinaisons projet.

Au sein d’un même contexte groupe et/ou projet, les différentes versions de contenus avec une langue différente sont appelés traduction.

Les trois propriétés permettant la recherche ou la création de déclinaisons (langue, groupe, projet) sont appelées pivot car les objets de contenus "tournent" autour de ces notions.

Par exemple, dans le cadre d’une traduction au sein d’un projet, les pivots communs sont le groupe et le projet, la langue étant le pivot de différentiation.

L’ensemble de ces objets sont liés par une propriété commune unique appelée master-key (propriété master dans l’objet).

Principes techniques

Chaque objet désirant hériter du principe de gestion de déclinaison doit être créé à partir de l’objet contentobject disponible dans le produit.

Cet objet dispose des propriétés et configurations nécessaires à la gestion de contenu :

La propriété master: master-key permettant la liaison avec l’ensemble des déclinaisons. L’ensemble des déclinaisons d’un même objet de contenu ont la même valeur dans ce champ.
Cette propriété est gérée par le système via les déclencheurs Wedia.
Cette propriété est définie par Wedia et ne peut être modifiée.
Pour fonctionner correctement il est nécessaire que les déclencheurs soient bien exécutés lors de l’insertion des objets possédant cette propriété.
La propriété mediagroup: liaison à un groupe. Les objets de contenus étant cloisonnés au sein d’un groupe, si vous désirez exploiter correctement la gestion de contenu avec les notions de contenu groupe et/ou de déclinaison projet.

Important

cette propriété est obligatoire sur l’objet.

La propriété media: liaison avec un projet. Si la valeur est vide, alors le contenu sera un contenu groupe.
La propriété lang: liaison avec les langues. Permet la gestion de la traduction. Ne peut être laissée vide
La propriété notranslation: si un contenu n’est pas fonctionnellement traduisible (par exemple une image), cette propriété permet de passer outre l’information de langue et d’empêcher la traduction de l’objet.

Caution

Pour une entité de contenu, la propriété master doit toujours être définie. La valeur de cette propriété est définie via les déclencheurs Wedia. Il est donc important de ne pas désactiver l’exécution des déclencheurs lors des insertions et modifications d’une entité de contenu.
Par ailleurs cette valeur ne pouvant être modifiée dès lors qu’elle a été définie il est recommandé de cacher la propriété et la rendre non-éditable dans les écrans du back-office.

Caution

La notion d’entité de contenu n’est pas à confondre avec la notion d’objet de contenu décrite en configuration d’objet en mode structure. Que l’objet soit porteur ou non de cette information n’a pas d’incidence sur la gestion des entités sauf exceptions précises (cf proposition / imposition dans déclinaisons projet et principe d’héritage).

Configurations et héritages

Une structure d’objet peut être configurée de trois façons :

objet système
objet technique
objet de contenu

La "destination" des objets à décliner est possible suivant l’ensemble des pivots sauf dans la cas des objets configurés comme objet de contenu.

En effet, dans ce cas précis, un paramétrage accessibles aux contributeurs permet de restreindre les cadres de création / exploitation des objets à certains contextes.

Par exemple, sur votre plate-forme, si vous avez les objets suivants :

article: configuré objet de contenu, possède les pivots langue, groupe et projet
galleryelement: configuré objet de contenu, possède les pivots langue, groupe et projet
product: configuré objet de contenu, possède les pivots langue, groupe et projet
theme: configuré objet technique, possède les pivots langue, groupe et projet

Par défaut, les deux objets seront déclinables dans l’ensemble des groupes et projets mais vous pouvez configurer votre application pour indiquer qu’ils seront limités aux accès aux objects article et galleryement.

La configuration de cette liste passe par la complétion du champ contentobjects et peut se faire à plusieurs niveaux :

sur le canal
sur le groupe
sur le projet
sur le modèle

Nous livrons par défaut un ensemble de personnalisations sur le champs contentobject afin que la contribution soit simplifiée et explicitée : l’utilisateur n’aura plus qu’à cocher les éléments qu’il veut sélectionner.

Le niveau de configuration le plus "haut" est structurel : toutes les structures d’objets déclinables (donc avec la master-key) sont utilisables.

Si la configuration n’est pas effectuée, nous calculons nous-même ce qui est exploitable à chaque niveau via un héritage de configuration :

Le canal hérite du modèle de données
Le groupe hérite du modèle de données
Le projet hérite par défaut de l’intersection des objets disponibles sur le canal et sur le groupe
- on peut étendre la sélection parmi les objets du groupe (et donc exploiter des objets normalement non sélectionnable par ce canal)
Le modèle hérite par défaut de l’intersection des objets disponibles sur le canal et sur le groupe
- on peut étendre manuellement la sélection parmi les objets du groupe (et donc exploiter des objets normalement non sélectionnable par ce canal)
Le support hérite par défaut de l’intersection des objets disponibles sur le modèle (si il en a un, sinon du canal) et sur le projet.

Caution

Nous ne permettons pas par défaut de sélectionner au niveau du projet les objets exploitables lorsque celui-ci fait parti d’un canal layout-driven car, d’un point de vue fonctionnel, cette sélection est dépendante des modèles exploités (surtout si dans votre projet, vous créez plusieurs supports).

Exemple :

L’utilisateur a personnalisé la sélection pour le groupe et le canal
L’utilisateur n’a pas personnalisé la sélection sur le projet et le modèle ⇒ ils hériteront donc de l’intersection du canal et du groupe.

Tip	Les objets techniques et systèmes étant implicitement toujours exploitables, depuis la version 10.5, la liste des objets sélectionnables dans le back-office sur la propriété `contentobjects` ne comportent que les objets dont la configuration indique `objet de contenu`. == Création de contenu

Lors de la création d’un objet contextualisable suivant une des trois variables gérées par le système, un portail de sélection peut apparaître.
Cela indique que le système n’a pas pu déterminer l’ensemble des informations nécessaires pour le créer; que ce soit par héritage (avec les collections) ou par l’url d’appel.
Dans ce cas, il imposera à l’utilisateur de sélectionner un contexte valide avant de saisir des informations dans le formulaire.

Les informations présentées dans ce portail dépendent de l’objet même (quels champs il possède et quelles sont les informations manquantes), de la configuration des projets et de l’utilisateur :

si l’information de groupe est manquante, on proposera la liste de groupe auxquels l’utilisateur est assigné.
- si l’objet est traduisible, on proposera de sélectionner une des langues ouvertes à la contribution pour l’utilisateur.
si l’information de projet est manquante, on proposera la liste des projets au canal content-driven auxquel l’utilisateur est assigné.
- si on avait déjà l’information de groupe, nous ne proposerons que les projets de celui-ci.
si l’information de langue est manquante, on proposera de sélectionner une des langues ouvertes à la contribution pour l’utilisateur et compatible avec les informations de groupe / marques précédentes.

Les informations de contexte sont, après validation, transmise à toutes les pages et urls dessinées permettant ainsi un héritage de contexte.

Créer ses propres urls contextualisées :

La contextualisation de création d’objet est effectuée en passant en paramètre à l’action datanew les infos du contexte sélectionné.

Ces paramètres sont les suivants :

wxm_group	id du groupe où on veut créer le contenu;
wxm_media	id du media où on veut créer le contenu (0 signifie que le contenu sera un contenu groupe);
wxm_lang	id de la langue du contenu.

Ces informations sont ensuite traitées par le système pour être validées. Une mauvaise contextualisation peut entraîner l’annulation de la partie erronée :

Si vous précisez le groupe + le projet : si le projet n’appartient pas au groupe visé, ce paramètre sera ignoré, il sera demandé de sélectionner un projet correcte
Si vous précisez une langue : si elle n’appartient pas au projet visé ou ne fait pas parti des langues du contributeur, il sera demandé de sélectionner une langue correcte.

Exploitation des contenus

Le système alimente automatiquement les bases objets suivant les affectations de l’utilisateur.

base_list_[objet]

La base base_list_[objet] sera compilée et alimentée dès lors que l’on dispose en request d’un form_objet valide.

Elle sera complétée de telle façon à voir :

les objets groupe auxquels l’utilisateur a accès
les déclinaisons projets auxquelles l’utilisateur a accès et dont le canal est content-driven
les déclinaisons dans les langues auxquels l’utilisateur a accès ou étant déclarées non traduisibles.

base_edit_list_[objet]

Les bases base_edit_list_[objet] de tous les objets dont la structure possède la master-key (propriété master) sont compilés et disponibles sur chaque page du back-office.

Elle seront complétée de telle façon à pouvoir utiliser :

les contenus groupe auxquels l’utilisateur a accès
les déclinaisons projets auxquelles l’utilisateur a accès et dont le canal est content-driven
les déclinaisons dans les langues auxquels l’utilisateur a accès ou étant déclarées non-traduisibles.

Caution

Ce paramétrage implique donc qu’une déclinaison projet peut se voir assigner un contenu groupe. Si vous ne désirez pas ce mode de fonctionnement et cloisonner vos contenus groupe/projet, vous devrez alimenter vos variables base_edit_list_[objet] dans /bov3/common/init/intBaseEditWhere.jsp vous-même