Bonjour,
J’ai un début de solution pour vous sur la partie WUI strictement, mais je n’ai pas trouvé de moyen simple de créer un nouveau wedlet autrement qu’en créant un nouvel éditeur qui pointe vers celui-ci. En imaginant que ça soit une solution envisageable, il « suffit » de créer et de lier à votre modèle « docLinkRoot » un nouveau wedlet pour préciser ce qu’il manque afin d’obtenir votre rendu. En l’occurence, il ne manque pas grand chose ! J’ai testé sur Builder 6.1.
Je vais essayer de fournir une réponse un peu détaillée de mon processus de recherche, en espérant que ça vous donne quelques outils pour la suite. La réponse est à la fin 
Je ne suis pas non plus un expert en wedlets, alors il y aura peut-être des approximations ! Le processus de résolution de problème me paraît tout de même intéressant.
Quel est le problème ?
De la même manière que les transf ordonnent la transformation d’un modèle dans un générateur, les wedlets ordonnent la « transformation » (l’affichage) des modèles dans l’éditeur de texte. Néanmoins, à la différence des transf, les wedlets s’inscrivent dans une logique de surcharge : si un wedlet n’est pas déclaré, le champ se comporte « par défaut ».
Pour voir ce qu’il se passe, commençons par l’éditeur. Concentrons-nous sur ces quelques lignes déjà bien chargées :
<box-ctn skin="box/head-body" skinOver="box/head-body/float" class="sm-root labelRoot" wed-name="dk_doclinkroot#" slot="0" tabindex="0">
<style xmlns="http://www.w3.org/1999/xhtml" data-code="box/head-body"></style>
<style xmlns="http://www.w3.org/1999/xhtml" data-code="box/head-body/float"></style>
<div class=head></div>
<div class=body></div>
</box-ctn>
En cherchant le coupable, je me rends compte que le div de classe head n’est pas correctement stylé. En effet, il a une règle CSS « float:left » qui l’autorise à être sur la même ligne que le bloc suivant.
Voyant cela, je remonte dans la balise parente : les balises box-xxx sont des représentations html des wedlets, et contiennent donc des informations précieuses sur leur comportement. En l’occurence, les attributs skin et skinOver de box-ctn montrent quelles règles CSS sont automatiquement liées à ces wedlets. On devine le coupable : skinOver vaut « box/head-body/float » ! Ce float là est source de suspicion.
Pour vérifier, dans Builder, on regarde le formulaire qui contient les règles générales (/dkWui/edit/form2c/form2c.wed en 6.1). Les balises sharedCSS décrivent quel feuille de style (attribut fileName) correspondent à quelle règle (attribut key). box_head_body_float.css contient bien une règle
.head {
float:left;
}
Maintenant, dernière étape : pourquoi cette règle est-elle apposée à votre modèle. J’ai dit tout à l’heure que les wedlets surchargeaient le comportement par défaut. On s’attendrait donc à avoir ici un champ sans instructions spécifiques. Seulement, quand je suis allé dans mon formulaire (celui qui contient la liste des instructions CSS, je suis aussi allé voir, par conscience professionnelle ( 
), la liste des wedlets liés dans /dkWui/edit/form2c/form2c.wdllist. La liste « common » a attiré mon attention : c’est un nom très générique. Et en effet, on y trouve des wedlets génériques qui viennent surcharger tous les modèles non déclarés. xHead.wdl, par exemple, s’applique à tous les compositionPrim, dont votre modèle !
Il existe plusieurs façons de lier des règles CSS à un widget. Dans ce xHead.wdl, le fait d’indiquer layout=« float » suffit à lier automatiquement la bonne feuille (par un processus que je ne saurais pas vous expliquer). On pourrait aussi avoir, de manière équivalente, un attribut appendSharedCssKey=« box/head-body/float » dans le container.
En tous les cas, voilà la déclaration coupable ! Il faut donc explicitement mentionner le fait que votre modèle ne suivra pas ce wedlet générique.
Comment résoudre le problème ?
Il faut donc déclarer un nouveau wedlet. Dans un contexte autre que celui d’une extension, il faudrait créer un nouveau objet .wdl et le lier via une wedlist. Ici, je ne connais pas d’autre solution que de recréer un éditeur, mais ça n’est pas une solution très satisfaisante. Dans ce cas, il faudrait donc créer un nouvel éditeur, avec un formulaire calqué sur votre cible, avec pour seule modification l’ajout de ce wedlet (aïe !).
Ici, au moins, il y a plusieurs solutions. Il faut préciser qu’on attend autre chose qu’un layout « float ». Donc, on peut :
- Préciser layout=« vertical » dans le headBodyWidget de la racine.
- Préciser un skin pour le container de ce headBodyWidget, typiquement sans le float (appendSharedCssKey=« box/head-body »
- on pourrait aussi reconstruire le wedlet en entier via un openEdtWidget. C’est ce que j’avais fait au début avant de me rendre compte qu’il suffisait de changer un attribut.
