Joe Ramone wrote:
> 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 ?
en fait il n'y a rien à migrer en ce qui concerne les thèmes, il suffit
de changer la version de CPS et de faire un 'rebuild themes'. Pour les
portlets il suffit de les mettre à jour (rebuild portlets) pour qu'ils
aient le même schéma que le version courante de CPS.
concernant les portlets tant que l'API utilisée est l'API officielle il
n'y a rien à modifier. Ensuite les portlets sont eux aussi complètement
encapsulés, ils ne dépendent d'aucune macro ZPT extérieure ce qui
n'était pas du tout le cas des boîtes ...
> 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).
tout dépend du portlet utilisé, mais modifier l'ordre d'affichage est
déjà pris en compte par la plupart des portlets dont les items sont
triables. Tous les cas d'utilisation génériques sont déjà intégrés,
sinon il suffit des le rajouter (cf. demander un compte svn)
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.
comme c'est un préjugé il est difficile d'argumenter, même dans la
pratique on gagne du temps..
/JM
_______________________________________________
cps-users-fr
Adresse de la liste : [email protected]
Gestion de l'abonnement : <http://lists.nuxeo.com/mailman/listinfo/cps-users-fr>
