D'abord, merci beaucoup pour cette réponse rapide.

> La version 3.3.8.1 de CPS propose en effet une fonction similaire pour le 
> type 
> de document File (en fait, tous les documents qui ont un champ nommé 'file').
> 
> En particulier les changesets suivants vous guideront:
> https://svn.nuxeo.org/trac/pub/changeset/26907
> https://svn.nuxeo.org/trac/pub/changeset/26906
> 
> Bien que le code ait été un peu amélioré par la suite.

Dans un premier temps, ça serait pas mal qu'on mette à jour.
 
> https://svn.nuxeo.org/trac/pub/file/CPSDefault/trunk/skins/cps_default/getContentInfo.py

Bon, ça, ça parait jouable, on rajoute autant de champs que l'on
souhaite dans le dict de retour et ça devrait aller.

> https://svn.nuxeo.org/trac/pub/file/CPSDefault/trunk/skins/cps_default/content_lib_info_detail.pt

Là, par contre, ça se gâte un peu. Optimalement, il faudrait pouvoir
utiliser un template par type de doc. Ça serait certainement le plus
propre. Et puis tant qu'à faire, il faudrait tagger dans le template de
chaque type de doc les fields/meta à rendre visible dans la preview.
Yaka.

> Si vous voulez réaliser un comportement similaire pour les types de doc ayant 
> des pieces jointes flexibles (ie en nombre variable), il faut etre un peu 
> plus 
> sioux pour déterminer quels sont les fields intéressants dans getContentInfo 
> et 
> les exploiter cet info dans la template.

Oui, en effet, ça risque d'être un peu sale, il va ptet falloir revoir
le coût de level 1 à la hausse :)

Bonne soirée et bon week end !

-- 
Jérôme Andrieux
_______________________________________________
cps-users-fr
Adresse de la liste : [email protected]
Gestion de l'abonnement : <http://lists.nuxeo.com/mailman/listinfo/cps-users-fr>

Répondre à