Joe Ramone a écrit :
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.
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.
--
Olivier
_______________________________________________
cps-users-fr
Adresse de la liste : [email protected]
Gestion de l'abonnement : <http://lists.nuxeo.com/mailman/listinfo/cps-users-fr>
