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
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
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).
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-keypermettant 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-drivenles déclinaisons dans les langues auxquels l’utilisateur a accès ou étant déclarées non-traduisibles.
...
...
The Wedia solution is designed to manage in a simple and easy way all of your documents, texts and media in order to be consistent within different channels.
This section will detail all the available features.
Object entity
Functional principle
A declined object is functionally represented as an entity. It is broken down according to three criteria:
the group
the project
the language
When an object possesses its three notions, one obtains the schema of principle next:
The same entity of this content in Group A can be observed here, which is broken down as follows in this way:
- outside group
English version
French version
- project 1
Japanese version
English version
- project 2
French version
English version
- project 3
French version
English version
Naming conventions
Excluding the concepts of layout-driven or content-driven projects, the following will name objects not related to a project: group content.
The versions of this content in a project are called project explosions.
Within the same group and/or project context, the different versions of content with a different language are called translation.
The three properties allowing the search or creation of declinations (language, group, project) are called pivot because the objects of content "revolve" around these notions.
For example, in the context of a translation within a project, the pivots are the group and the project, language being the pivot of differentiation.
All these objects are linked by a single common property called master-key (property master in the object).
Technical principles
Each object wishing to inherit the declination management principle must be created from the contentobject object available in the product.
This object has the properties and configurations necessary to content management:
- Property
master master-keyallowing the connection with all of the variations. All declensions of the same content object have the following characteristics same value in this field.
This property is managed by the system via the Wedia triggers.
This property is defined by Wedia and cannot be changed.
To function properly it is necessary that the triggers are well executed when inserting objects with this property.- Property
mediagroup linking to a group. Content objects are within a group, if you want to exploit correctly content management with the notions of group content and/or content management project declination.
Important | This property is mandatory on the object. |
- Property
media connection with a project. If the value is empty, then the content will be a group content.
- Property
language connection with languages. Allows translation management. Cannot be left empty.
- Property
notranslation if a content is not functionally functional it cannot be translated (e.g. an image), this property allows you to pass in addition to language information and prevent translation of the object.
Caution | For a content entity, the master property must always be defined. The value of this property is set via Wedia triggers. It is therefore important not to disable the execution of triggers when inserting and modifying a content entity. Moreover, since this value cannot be modified once it has been defined, it is recommended to hide the property and make it non-editable in the back office screens. |
Caution | The notion of content entity is not to be confused with the notion of content object described in object configuration in structure mode. Whether or not the object is the carrier of this information has no impact on the management of the entities with specific exceptions (see proposal / taxation in project declinations and inheritance principle). |
Configurations and inheritance
An object structure can be configured in three ways:
system object
technical object
content object
The "destination" of the objects to be declassified is possible according to the set of objects to be declassified. Pivots except in the case of objects configured as content objects.
Indeed, in this specific case, a configuration accessible to contributors allows you to restrict the settings for creating / evaluating objects to some contexts.
For example, on your platform, if you have the following objects:
- article
configured content object, has language, group and project pivots
- galleryelement
configured content object, has language, group and project pivots
- product
configured content object, has language, group and project pivots
- theme
configured technical object, has language, group and project pivots
By default, both objects will be available in all groups and projects but you can configure your application to indicate that they will be limited to access to the objects article and item.
The configuration of this list goes through the completion of the field contentobjects and can be done on several levels:
on the channel
on the group
on the project
on the model
We deliver by default a set of customizations on the fields contentobject so that the contribution is simplified and explained: the user will only have to tick the elements that she wishes to use.
The highest configuration level is structural: all object structures that can be declined (thus with the master-key) are usable.
If the configuration is not carried out, we calculate ourselves what can be used at each level via a configuration inheritance:
The channel inherits the data model
The group inherits the data model
The project inherits by default the intersection of the available objects on channel and on the group
you can extend the selection among the group objects (and thus to exploit objects normally not selectable by this channel)
The model inherits by default the intersection of available objects on the channel and on the group
you can manually extend the selection among the group objects (and thus to exploit objects normally not selectable by this channel)
The support inherits by default the intersection of available objects on the model (if it has one, if not the channel) and on the project.
Caution | By default, we do not allow you to select at the project level exploitable objects when it is part of a channel layout-driven because, from a functional point of view, this selection is dependent on the models evaluated (especially if you are creating multiple media in your project). |
Example:
User customizes selection for group and channel
The user did not customize the selection on the project and the model ⇒ they will inherit the intersection of the channel and the group.
Tip | Technical objects and systems are always implicitly exploitable, since version 10.5, the list of selectable objects in the back-office on the contentobjects property only include objects whose configuration indicates content object. |
Content creation
When creating a contextualisable object according to one of the three variables managed by the system, a selection portal may appear.
This indicates that the system could not determine all the information needed to create it; either by inheritance (with collections) or by the call URL.
In this case, it will require the user to select a valid context before entering information in the form.
The information presented in this portal depends on the object itself (what fields it has and what information are missing), the configuration of the projects and the user:
If group information is missing, the group list will be proposed to which the user is assigned.
If the object is translatable, it will be proposed to select one of the languages open to user input.
If project information is missing, a list of projects will be proposed to the content-driven channel to which the user is assigned.
If we already had the group information, we’ll only propose the most important projects.
If the language information is missing, you will be prompted to select a language that is open to user input and compatible with group information / previous brands.
The context information is, after validation, transmitted to all pages and URLs drawn allowing a legacy of context.
Create your own contextualized URLs:
The contextualization of object creation is carried out by passing in parameter to the action datanew the info of the selected context.
These parameters are as follows:
| wxm_group | ID of the group where you want to create the content |
| wxm_media | ID of the media where you want to create content (0 means that the content will be a group content |
| wxm_lang | ID of the content language |
This information is then processed by the system for release. Improper contextualization can result in the erroneous part being undone:
If you specify the group and project:
If the project does not belong to the group, this parameter will be ignored, you will be prompted to select an correct projectIf you specify a language:
If it does not belong to the project in question, or if it is not part of the contributor’s languages, you will be asked to select a correct language.
Use of contents
The system automatically feeds the object bases according to the user’s assignments.
base_list_[object]
The base_list_[object] database will be compiled and populated as soon as you have a valid form_object in request.
It will be completed in such a way as to show:
group objects to which the user has access
the project declinations to which the user has access and whose channel is content-driven
declinations in the languages to which the user has access or which are declared untranslatable.
base_edit_list_[object]
The base_edit_list_[object] bases of all objects whose structure owns the master-key (owner master) are compiled and available on every page of the back office.
It will be completed in such a way that it can be used:
group contents to which the user has access
project versions to which the user has access and whose channel is
content-driven.versions in languages to which the user has access or which are declared non-translatable.
Caution | This setting implies that a project declination can be assigned a group content. If you do not want this mode of operation and to partition your contents group/project, you will have to feed your base_edit_list_[object] variables in /bov3/common/init/initBaseEditWhere.jsp yourself. |