Joe Ramone wrote:
Modifier les macros ZPT / main_template.pt rend plus compliquée la
mise
à jour du logiciel, vers de nouvelles versions ou simplement pour la
correction de bugs. A l'arrivée (1 an, 2 an après) il y a plus
d'inconvénients à utiliser cette méthode.
Lorsqu'un projet évolue vers une nouvelle version de CPS, le design
n'est pas sensé changé.
oui, mais si vous modifiez les templates livrés avec CPS, (y compris le
main_template.pt) il faudra les réécrire. Dans la plupart des cas c'est
un perte de temps. Les seuls templates que l'on est souvent obligé de
modifier sont les formulaires (login_form, search_form, ...) mais leur
nombre est limité. ce qui permet de simplifier le travail de migration.
L'utilisation de templates ZPT permet justement d'être assez
indépendant des versions de CPS (sous réserve de compatibilité d'API) .
évidemment que non, puisque vous modifiez les ZPTs qui sont livrés avec
l'appli. C'est facile à réaliser (n'importe quel webdesigner avec un
minimum de connaissances en HTML sait faire) Mais cela demande de suivre
constamment les évolutions de CPS. Avec CPSSkins, vous n'avez qu'à
mettre à jour l'application est vous n'avez pas à modifier un seul page
template.
dans le passage de CPS3.2 à CPS3.4, les thèmes sont réutilisables
directement. Les difficultés de migration actuelles (?) peuvent dans
certains cas provenir du remplacement des boîtes par des portlets, mais
cela n'a rien avoir avec CPSSkins.
bref, l'intérêt et de séparer la logique de présentation du reste de
l'appli. Cela veut dire que les thèmes sont complètement encapsulés, et
une migration des thèmes existants vers Zope3 est rendu possible même si
la techno utilisée est complètement différente.
En somme tout dépend si pour vous l'investissement dans la création
d'un thème est plus ou moins importante que le temps que vous allez
passer à recréer vos thèmes tous les 1 ou 2 ans (difficile à motiver
d'un point de vue économique aussi)
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.
c'est faux. J'ai fait passer le site d'europython.org de CPS3.2 vers
CPS3.4, sans réécrire un seul portlet. Il y a une bannière de pub qui
tourne, un menu dynamique, un portlet de recherche sous Ajax
(llivesearch...)..
cf. http://www.europython.org
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 ?
CPSSkins et CPSPortlets prennent en charge les modifications de l'API de
CPS, y compris les optimisations.
Question subsidiaire : quel est le rôle de CPSSkins dans le design
d'un portlet ?
aucun, c'est CPSPortlets qu'il faut utiliser CPSSkins ne fait
qu'afficher le portlet à un endroit de la page et lui assigne un style.
/JM
_______________________________________________
cps-users-fr
Adresse de la liste : [email protected]
Gestion de l'abonnement : <http://lists.nuxeo.com/mailman/listinfo/cps-users-fr>
