Wiki - 1 output

Dans un contexte respectant l’indépendance des fonctionnalités utilisateurs, les différentes composantes optionnelles qui peuvent étendre les capacités d’une classe, ainsi que cette classe, n’ont pas connaissance les unes des autres.

Pour respecter cette indépendance, mais malgré tout permettre de définir certains éléments transverses, un fichier exhaustive.yaml peut être défini à la racine de chaque projet module logiciel.

Il permet de définir :

- l’ordre dans lequel l’ensemble des propriétés possibles pour chaque classe seront rangés,
- l’ordre dans lequel les blocs de menus et des éléments de menus seront rangés.

Structure du fichier

Le fichier contient la liste des classes (chemin complet), et permet de définir pour chacune :

- display_order : dans quel ordre seront rangées (notamment affichées par défaut dans les vues) les propriétés.
- ordering : Pour la classe Menu du framework : dans quel ordre ranger les blocs de menu, et les éléments de menus.

Enrichissement par héritage

Les fonctionnalités des classes et les menus peuvent être étendus par des applications héritant d’autres applications.
De la même façon, exhaustive.yaml peut enrichir les données transverses à ces classes, et ces menus.
Pour se faire, les paramétrages du fichier exhaustive de l’application fille seront cumulés aux fichiers exhaustive des applications parentes. Pour les paramètres ordonnant les propriétés / menus les uns par rapport aux autres :

- Il suffit de rappeler une propriété déjà paramétrée dans @display_order de la classe ou du exhaustive.yaml parent pour que toutes les nouvelles propriétés qui suivent soient rangées après cette propriété. Inutile de rappeler l’ordre des propriétés déjà défini : celui-ci sera conservé.
- De même, les nouvelles propriétés qui précèdent une propriété déjà paramétrée dans @display_order de la classe ou du exhaustive.yaml parent seront rangées avant cette propriété.
- Les mêmes règles s’appliquent pour les blocs de menus et des éléments de menus.

Exemples

Au sein d’une application

Soit une classe Item Définie dans une application A, avec les propriétés $code et $name.
Soit un trait Has_Description, fonctionnalité utilisateur qui peut être ajoutée optionnellement à l’article, mais aussi à d’autres classes, avec la propriété $description.
La classe et le trait doivent respecter une totale indépendance, donc ne peuvent pas avoir connaissance des propriétés l’une de l’autre, ni inversement.
exhaustive.yaml peut contenir le tri de ses propriétés en cas d’assemblage :

My\Application_A\Item:
  display_order:
    - code
    - name
    - description

Depuis une application héritée

Soit un trait Has_Price, défini dans une application B, application héritée de A, avec la propriété $price.
Ce trait peut également être appliqué à Item, mais à d’autres classes. Item n’a pas à connaître l’application Has_Price, et inversement.
Le fichier exhaustive.yaml de l’application A ne peut pas avoir connaissance de la propriété d’un trait de l’application B : en effet si B connaît A, l’inverse n’est pas vraie, la dépendance entre applications devant être mono-directionnelle.
Le dossier de l’application B peut définir dans son exhaustive.yaml à quel endroit pourra être placé la propriété $price :

Soit en la faisant suivre la propriété nom :

My\Application_A\Item:
  display_order:
    - name
    - price

Soit en la faisant précéder la propriété description :

My\Application_A\Item:
  display_order:
    - price
    - description

L’effet sera le même, sauf si une troisième application C vient enrichir encore une fois la classe Item avec des propriétés à ranger juste après $name par exemple. Le rangement “avant” ou “après” définira la priorité avec laquelle ce rangement sera effectuée.
En cas d’héritage d’applications multiples, vous pouvez être amené à redéfinir dans votre application finale ou une application héritant de plusieurs applications l’ordre des champs des applications héritées pour vous assurer du tri des propriétés. Si la règle de rangement peut être résolue de plusieurs manières, par exemple dans le cas de deux applications ajoutant des propriétés après la même propriété d’une application parente commune, mieux vaut définir l’ordre de tri final pour être sûr de le maîtriser.

Rangement des menus

Dans le cas de menus optionnels, installés par différentes fonctionnalités, les menus n’étant pas définir dans le fichier de configuration menu.php, vous devrez les ordonner pour vous assurer que vos menus seront bien rangés une fois les fonctionnalités installées.
Le fichier exhaustive.yaml contiendra donc la liste exhaustive des menus possibles pour un module logiciel, et les ordonnera par rapport aux applications parentes en respectant les mêmes règles d’héritage d’application que pour la liste des propriétés.

Chaque bloc de menu est identifié par son nom, qui doit en principe être unique dans l’ensemble d’applications.
Chaque entrée de menu est identifiée par le chemin d’accès à la fonctionnalité, en principe également unique, n’étant pas conseillé de multiplier les points d’entrée à une fonctionnalité identique dans les menus.

Par exemple :

ITRocks\Framework\Component\Menu:
  ordering:
    Parent_Menu_Bloc_1:
    Parent_Menu_Bloc_2:
      - /Application/B/New/Feature/Path
    New_Menu_Bloc_Comming_After_2:
      - /Application/B/Feature/Path/A
      - /Application/B/Feature/Path/B
      - /Application/B/Feature/Path/C