Gestion des classes publiques

Une classe acquiert donc le statut de "public" si elle est déclarée dans les sm:publicClasses du wspDef.

Si une classe a vocation à être externalisée, qu'elle n'est pas déclarée dans les sm:publicClasses du wspDef, et qu'elle est utilisée dans un sm:part d'une composition :

• si la part est en "userDependent", elle sera mise à disposition du rédacteur uniquement en internalisée.
• si la part est externalisée (internalized="never"), la part toute entière sera purement et simplement éliminée du modèle pour le rédacteur (pour être précis : si la part autorise plusieurs modèles, elle disparaît lorsque qu'aucun de ses sm:allowedModel n'est déclaré dans sm:publicClasses).

De même, si un modèle est référencé par une dataFormPrim (via un sm:refItem) ou dans un modèle textePrim (via un sm:inlineImgTag), mais qu'il n'est pas déclaré dans les sm:publicClasses :

• le field du dataForm ou l'inclusion de l'image inline seront supprimés du modèle pour le rédacteur.

Intérêt de créer un sous-ensemble d'un modèle

Cette modif permet donc de créer des wspDef comportant un sous-ensemble des modèles disponibles.

Avec un modèle exemplaire comme showOrg, l'idée est de pouvoir réduire très rapidement la liste des modèles disponibles en fonction des besoins de chaque organisation. Par exemple :

• ne pas mettre à disposition d'une entreprise les modèles de services, les produits et les projets
• ne pas mettre à disposition d'une association, la fiche entreprise, etc

Exclusion de modèles (sm:removeInternClass)

(et limites de ce mode de surcharge)

Néanmoins, un cas n'est pas traité : si les classes publiques sont bien éliminées pour le rédacteur, les classes internalisées ne sont pas supprimées. Par exemple, la ficheService de showOrg peut être éliminée des classes publiques et ne sera plus proposée comme item externalisé dans une section, mais sera toujours proposée en mode internalisé.

Pour permettre l'élimination complète d'un .model, y compris dans sa forme internalisée, on a ajouté la possibilité dans un wspDef d'exclure les formes internalisées d'un modèle. (voir les les balises sm:overlays/sm:removeInternClass).

En attendant (peut-être un jour, dans la version 4...) une vrai gestion des notions de surcharge (pour décliner des modèles documentaires, mais aussi des contenus), cette solution permet de créer des modèles "complets" et de les personnaliser en sciant proprement des branches. Attention, ça n'est pas la panacée, ça ne répond qu'à une des formes de déclinaison de modèles documentaires, et il y a des cas où il est impossible d'éliminer un modèle : par exemple, lorsqu'il constitue à lui seul, une des 2 options d'une alternative, sa suppression impliquerait une réécriture de la logique du modèle appelant. Malgré ces inconvénients, cette solution devrait nous rendre bien service dans tous nos modèles "génériques" et "à tiroir" comme showOrg ou Dokiel.

Dernière chose : avec ce principe, nous créons des modèles documentaires (MD) incompatibles entre eux, ce qui n'est pas gênant pour showOrg. Il y a d'autres cas où on voudrait créer des wspDef avec des potentiels d'édition différents mais "partageant" le même MD : des wspDef débutants/experts, des wspDef correspondant à différents métiers, etc. On pourra envisager plus tard une option supplémentaire dans les surcharges d'un wspDef (sm:overlays/sm:hideClass) qui permet au MD d'avoir connaissance de l'intégralité du modèle mais de ne proposer qu'un sous-ensemble à l'édition.