> Lorsqu'un projet évolue vers une nouvelle version de CPS, le design
> n'est pas sensé changé. L'utilisation de templates ZPT permet justement
> d'être assez indépendant des versions de CPS (sous réserve de
> compatibilité d'API) . Si on utilise uniquement les portlets
> "Nuxeo/CPSSkins" qui sont automatiquement migrés ça a son avantage mais
> un site commercial nécessite souvent le développement de portlets
> spécifiques qui ne sont pas pris en charge par les migrations. Exemple :
> un portlet "header" qui affiche une image aléatoirement issue d'une
> gallerie + des liens vers les sous-dossiers de l'espace courant.
En théorie oui mais dans la pratique c'est difficilement réalisable. De plus
l'utilisation de CPSSkins + la programmation de portlet custom permet de
réaliser des chartes graphiques complexes en quelques jours seulement contre
plusieurs semaines avec l'ancien système. Mais c'est vrai que la maîtrise des
subtilités de CPSSkins demande de l'expérience mais reste relativement plus
simple que l'ancien système.
> Le principal problème lors d'un changement de version est la
> modification de l'API CPS or quelle solution CPSSkins apporte-t'il au
> problème ?
Un format XML d'import/export indépendant de l'API de CPS.
Ok si je comprend bien : on peut migrer les "templates" CPSSkins d'un site vers un autre via un import/export XML. Cette procédure de migration est de plus compatible avec toute les versions de CPS supérieures à 3.4. Donc en gros désormais pour chaque version de CPS vous redéveloppez les portlets qui le nécessitent pour suivre l'API. En quoi est-ce une avancée pour les développeurs qui développent leurs propres portlets et n'utilisent pas les votres ?
> Question subsidiaire : quel est le rôle de CPSSkins dans le design d'un
> portlet ?
La plupart des portlet fournis en standard dans CPS sont prévus pour exploiter
au mieux les CSS générées par CPSSkins mais rien n'empeche d'écrire ces CSS à la
main et d'appeler le rendu des portlets programmatiquement depuis un
main_template personnalisé comme l'a dit JMO.
Entendu donc pour modifier en profondeur le design d'un boite je serai quand même obligé de modifier la présentation du portlet (par exemple pour inverser l'affichage d'élements). Dans ce cas autant mieux, enrichir la vue HTML du portlet avec des classes et utiliser sa propre feuille CSS. Le gain de temps dont vous parlez ne me parait pas évident.
_______________________________________________ cps-users-fr Adresse de la liste : [email protected] Gestion de l'abonnement : <http://lists.nuxeo.com/mailman/listinfo/cps-users-fr>
