29-11-2011 : Remettre dans le débat politique les principes du Conseil National de la Résistance
17-02-2012 : Pétition pour une protection de l’apiculture et des consommateurs face au lobby des OGM
Logo de mon site
Logo de mon site
Faire un don




Right menu

Logo du site ez.no  Logo XHTML 1.O du W3C  Logo XHTML 1.O du W3C  Site francophone officiel de Firefox
zero papier grâce aux catalogues et promos en ligne de bonial

Content management -- Gestion de contenu

Table des matières

  1. Content management -- Gestion de contenu
  2. Datatypes -- Types de données
  3. The content class -- La classe de contenu
  4. Class attributes -- Attributs de classe
  5. The content object -- L'objet de contenu
  6. Object versioning -- Gestion des versions des objets
  7. Multiple languages -- Plusieurs langues
  8. The content node -- Le noeud de contenu
  9. The content node tree -- L'arbre de noeuds de contenu
  10. Top level nodes -- Noeuds de niveau supérieur
  11. Node visibility -- Visibilité des noeuds
  12. Object relations -- Relations entre objets
  13. Sections -- Les sections
  14. URL storage -- Stockage d'URL
  15. Information collection -- Collecte d'informations

Object versioning -- Gestion des versions des objets

Date de publication: le mardi 22 mars 2011 à 18h00
Dernière modification: par Pascal BOYER le vendredi 25 mars 2011 à 16h12

26/03/2007 11:35  

versions 3.9, 3.10

:
Ce document a été supprimé depuis la version 4.x de la documentation technique.

eZ Publish comes with a built in versioning system which is implemented at the object level. This mechanism makes it possible to have several versions of the contents (attributes) of an object. It basically provides a generic, out-of-the-box version control framework that can be used with any kind of content. The different versions are encapsulated by the object itself. The following illustration shows a more detailed example of the object structure seen from the outside world. 
eZ Publish fournit un système de gestion de versions implémenté au niveau des objets. Ce mécanisme permet d'avoir plusieurs versions du contenu d'un objet et fournit, par défaut, un framework de contrôle de versions pouvant être utilisé avec n'importe quel type de contenu. Les différentes versions sont encapsulées par l'objet lui-même. L'illustration suivante est un exemple plus détaillé de la structure d'un objet vue de l'extérieur:

 

 

Example of a content object that consists of two versions
Exemple d'un objet de contenu existant en 2 versions.

Every time an object is edited, a new version of the object's contents will be created. It is always the new version that will be edited, the old version(s) remains untouched. This is how eZ Publish keeps track of changes made by various users. An accidental or unwanted change can thus be undone by simply reverting an object back to the previous version. 
Chaque fois qu'un objet est édité, une nouvelle version du contenu de l'objet est créée. C'est toujours la nouvelle version qui est éditée, les anciennes versions restant inchangées. C'est ainsi que eZ Publish conserve une trace des changements apportés par les différents utilisateurs. Une modification accidentelle ou non souhaitée peut donc être annulée en revenant simplement à une version antérieure.

Version limitations / Limitation du nombre de versions

Since every edit procedure results in the creation of a new version (unless the new version is discarded), the database can be quickly filled up by different versions of the same content. In order to prevent this problem, the versioning system can be limited to a certain number of versions per object. It is possible to assign different version limitations for different object types (different classes). The default limitation is 10, which means that every object can have a maximum number of 10 versions of its content. If the maximum count is reached, the oldest version will be automatically deleted and thus a free slot will be available for the new one. This is the default behavior. An alternative setting can be used to disallow the creation of new versions until an existing version is manually deleted by a user. 
Puisque la procédure d'édition crée une nouvelle version (à moins que la nouvelle version soit abandonnée), la base de données peut rapidement être remplie par différentes versions d'un même contenu. Afin de prévenir un tel problème, le système de gestion des versions peut limiter le nombre de versions par objet. Il est possible d'assigner différentes limitations de versions pour différents types d'objets (différentes classes). La limitation par défaut est de 10, ce qui signifie que chaque objet contient au maximum 10 versions. Lorsque le nombre de version atteint la limite autorisée, les versions les plus anciennes sont automatiquement effacées, libérant ainsi la place pour les nouvelles. Ceci correspond au fonctionnement par défaut. Une configuration alternative peut être mise en œuvre en interdisant la création d'une nouvelle version jusqu'à ce que la version existante soit manuellement effacée par un utilisateur.

Version structure / Structure d'une version d'un objet

A version consist of the following elements: 
Une version se compose des éléments suivants:

  • Version number 
    un numéro de version
  • Creation time 
    une date de création de la version
  • Modification time 
    une date de modification de la version
  • Creator 
    un créateur
  • Status 
    un statut
  • Translations 
    une ou plusieurs traductions

Version number / Numéro de version de l'objet

Every version has a unique version number. This number is used by the system to organize and keep track of the different versions of an object. The version number is automatically increased for each version that is created inside an object. 
Chaque version d'un objet a un numéro unique. Ce numéro est utilisé par le système pour organiser et conserver une trace des différentes versions d'un objet. Le numéro de version est automatiquement incrémenté à chaque version d'objet créée.

Creation time / Date de création de la version

The creation time contains a timestamp pinpointing the exact date and time when the version was initially created. This information is set by the system and will remain the same regardless of what happens to the version. 
L'heure de création contient, au format timestamp UNIX, la date et l'heure exactes de création initiale de la version. Cette information est paramétrée par le système et restera inchangée quoi qu'il advienne de la version.

Modification time / Date de modification de la version

The modification time contains a timestamp revealing the exact date and time when the version was last modified. This information is set by the system every time the version is stored and when the version is finally published. When a version is published, the modification time of the object itself will be updated (it will simply be set to the same value as modification time of the version that was published). 
L'heure de modification contient, au format timestamp UNIX, la date et l'heure exactes de modification de la version. Cette information est mise à jour par le système chaque fois que la version est stockée et lorsque la version est finalement publiée. Lorsqu'une version est publiée, l'heure de modification de l'objet lui-même est mise à jour (elle prendra simplement la même valeur que l'heure de modification de la version publiée).

Creator / Le créateur d'une version

The version's creator contains a reference to the user that created the version. Although a content object can only belong to a single user (revealed by the "Owner" field), each version may belong different users. The creator reference is set by the system when the version is created. It can not be manipulated and will not change even if the user who created the version is removed from the system. 
Le créateur d'une version contient une référence à l'utilisateur qui a créé la version. Bien que le contenu d'un objet ne puisse appartenir qu'à un seul utilisateur (indiqué par le champ "Créateur"), chaque version peut appartenir à différents utilisateurs. La référence au créateur, définie par le système lorsque la version est créée, ne peut être modifiée et ne sera pas changée même si l'utilisateur ayant créé la version est supprimé du système.

Status / Les différents statuts d'une version

The state of a version is determined by its status. There are five possibilities: 
L'état d'une version est déterminé par son statut. Il y a 5 possibilités:

  • Draft (0) 
    Brouillon (0)
  • Published (1) 
    Publié (1)
  • Pending (2) 
    En attente (2)
  • Archived (3) 
    Archivé (3)
  • Rejected (4) 
    Rejeté (4)

In eZ Publish versions 3.8 and later, there is an additional possibility: if a version of a content object is created but not modified (for example, if someone clicked an "Add comments" button but didn't actually post anything), the status of the version will be "Internal draft (5)". In the administration interface, status "5" drafts are called "untouched drafts". From 3.9, you can set the number of days, hours, minutes and seconds before an internal draft is considered old and removed by the internal_drafts_cleanup.php cronjob script. Another cronjob script called old_drafts_cleanup.php can be configured to remove status "0" drafts that have been in the system for a specified period of time. 
Dans les versions 3.8 et plus récentes de eZ Publish, existe une autre possibilité: si une version d'un objet de contenu est créée mais pas modifiée (par exemple, si quelqu'un clique sur Ajouter un commentaire mais ne publie finalement pas son post), alors le statut de la version sera Internal draft (5) (Brouillon interne (5)). Dans l'interface d'administration, le statut 5 des brouillons est appelé brouillon inchangé. Depuis la version 3.9, vous pouvez paramétrer le nombre de jours, d'heures, de minutes et de secondes avant qu'un brouillon interne soit considéré comme vieux et soit donc supprimé par le script cron internal_drafts_cleanup.php . Un autre script cron nommé old_drafts_cleanup.php  peut être configuré pour supprimer les brouillons présents sur le système depuis un certain temps et dont le statut vaut 0 (zéro).

A newly created version is a draft. This status will remain until that version becomes published. Although an object can have many versions, there can only be one published version (the others are usually drafts and archived versions). The published version can be considered as the "current" version and it is the one that is accessed when the object is viewed. A published version can not become a draft. However, it will become archived as soon as another version is published. The following illustration shows how the versioning system actually works. 
Une version nouvellement créée conserve le statut de brouillon tant que la version n'est pas publiée. Bien qu'un objet puisse contenir plusieurs versions, il ne peut y avoir qu'une seule version de publiée (les autres sont souvents des versions ayant le statut de brouillon ou d'archive). La version publiée, qui ne peut devenir un brouillon, est considérée comme la version courante et est utilisée lorsque l'objet est vu/affiché sur le site. L'illustration suivante montre comment fonctionne réellement le système de gestion des versions:

 

 

Overview of the object states
Vue générale des états d'un objet

The illustration above shows the most common states of a content object. When a new object is created (step 1), eZ Publish will also create a new draft version. Because the object has not been published yet, its status is set to draft and the current version is unknown. Storing the draft (steps 2a and 2b) will not change the state of the object. The only thing that will happen is that the contents of the draft will be stored in version 1. If the draft (which is the only existing version) is discarded, the object is completely removed from the system (step 2c). When the draft is published (step 2), both the draft and the object's states will be set to published. In addition, the current version will be set to 1, which reveals the currently published version of the object. When published, the contents of the object can be viewed by others. A published object can be removed/deleted from the system (step 3a). When removed, the object's state will be set to "Archived" and thus it will be in the trash. The object can be recovered from the trash to its previous state. Among other things, this involves the status field being set to "Published" again. When a published object is edited (step 4), the current version (version 1 in this case) will remain untouched and a completely new version will be created. The contents of the new version (version 2 in this case) will be a copy of the contents of the current version. Again, storing the draft (steps 4b and 4c) will not change the state of the object. If the draft is discarded (step 4a), it will be completely removed from the system and thus the object will be in the exact same state as it was in before it was edited. If the newly created and edited draft is published, it will become the current version of the object and thus the previous version (version 1 in this case) will be set to "Archived". Step 5a illustrates what would happen if the object (now with two versions) would be removed. 
- L'illustration ci-dessus présente les états les plus courants d'un objet de contenu. Lorsqu'un nouvel objet est créé (étape 1), eZ Publish crée également une nouvelle version de brouillon. Comme l'objet n'a pas encore été publié, son statut est positionné à brouillon et la version courante est inconnue.

- Si l'on enregistre le brouillon (étape 2a et 2b), cela ne modife pas l'état de l'objet. La seule chose qui se produit, c'est que le contenu du brouillon est stocké dans une version 1.

- Si le brouillon (qui est la seule version existante) est abandonné, l'objet est complètement supprimé du système (étape 2c). Lorsque le brouillon est publié (étape 2), son état et celui de l'objet sont positionnés à publié. De plus, la version courante est alors positionnée à 1 et représente la version actuellement publiée de l'objet. Lorsqu'il est publié, le contenu d'un objet peut être vu par les autres.

- Un objet publié peut être enlevé/supprimé du système (étape 3). L'état de l'objet passe alors à archivé et l'objet se retrouve dans la poubelle. Lorsque l'on récupère un objet dans la poubelle, son statut est celui qu'avait l'objet au moment où il a été placé dans la poubelle. Cela implique, entre autres, que le champ statut soit à nouveau positionné à publié.

- Lorsqu'un objet publié est édité (étape 4), la version courante (version 1 dans notre cas) reste inchangée et une toute nouvelle version est créée. Le contenu de cette nouvelle version (version 2) sera une copie du contenu de la version courante (version 1).

- A nouveau, si on enregistre le brouillon (étape 4b et 4c), cela ne modifie pas l'état de l'objet.

- Si le brouillon est abandonné (étape 4a) alors il est complètement supprimé du système et l'objet reste donc dans le même état, à savoir celui dans lequel il était avant d'être édité.

- Si le nouveau brouillon est publié, il devient alors la version courante de l'objet et la précédente version (version 1) devient une version archivée.

- L'étape 5a illustre se qui se passerait si un objet (contenant maintenant deux versions) était supprimé.

The pending and the rejected states are used by the collaboration system. When a version is waiting to be approved by an editor, the status is set to pending. If the version is approved, it will be automatically published and thus the status will be set to published. On the other hand, if a pending version is rejected by the editor, the status will be set to rejected .
Les états en attente et rejeté sont utilisés par le système de collaboration. Quand une version attend d'être approuvée par un éditeur, son statut est positionné à en attente. Si la version est approuvée, elle est automatiquement publiée et son statut passe donc à publié. En revanche, si une version en attente est rejetée par l'éditeur, son statut passe à rejeté.

A version can only be edited if it is a draft and it can only be edited by the same user who initially created it. In addition, rejected versions can also be edited. When a rejected version is edited, it will become a draft. Published and archived versions can not be edited. However, it is possible to make copies of them. When a published or an archived version is copied, the status of the copy is set to draft and thus it becomes editable. When/if the new draft is published, the system automatically sets the status of the previously published version to archived and the new draft will become the published version. 
Une version ne peut être éditée que par l'utilisateur qui l'a initialement créée et uniquement si elle est un brouillon. Par ailleurs, les versions rejetées peuvent tout de même être éditées. Alors qu'une version rejetée devient un brouillon lorsqu'elle est éditée, les versions publiées et archivées ne peuvent être éditées. Il est cependant possible d'en faire des copies dont le statut sera alors positionné à brouillon rendant ces copies éditables. Lorsque le nouveau brouillon est publié, le système positionne automatiquement le statut de la précédente version publiée à archivée et le nouveau brouillon devient la version publiée.

Translations / Traductions

The actual contents of a version is stored inside different translations. A translation is a representation of the information in a specific language. In other words, the translation layer allows a version of the object's actual contents to exist in different languages. A version always has at least one translation of the content (which represents the data in the default/standard language). 
Le contenu d'une version est stocké dans différentes langues/traductions. Une traduction est une représentation d'une information dans une langue spécifique. En d'autres termes, la couche traduction permet à une version du contenu d'un objet d'éxister en plusieurs langues. Une version contient toujours au moins une traduction du contenu (dans la langue par défaut (ou standard)).



Table des matières

  1. Content management -- Gestion de contenu
  2. Datatypes -- Types de données
  3. The content class -- La classe de contenu
  4. Class attributes -- Attributs de classe
  5. The content object -- L'objet de contenu
  6. Object versioning -- Gestion des versions des objets
  7. Multiple languages -- Plusieurs langues
  8. The content node -- Le noeud de contenu
  9. The content node tree -- L'arbre de noeuds de contenu
  10. Top level nodes -- Noeuds de niveau supérieur
  11. Node visibility -- Visibilité des noeuds
  12. Object relations -- Relations entre objets
  13. Sections -- Les sections
  14. URL storage -- Stockage d'URL
  15. Information collection -- Collecte d'informations

Commentaires