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.
Tout dépend des projets, personnellement j'ai du modifier plus de scripts que je ne le souhaitais sur CPS3 (pour corriger des anomalies ou bien pour modifier l'ergonomie). Sinon le main_template définit également les variables globales utilisées dans bcp des vues l'application, il est donc quasi obligatoire de le modifier à moins de livrer un site sans développement ou de définir les variables globales séparément ce qui n'est pas forcement plus propre ;)
> 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.
On s'est sans doute mal compris. Pour moi le ZPT est indépendant de CPS car il fonctionne en standard sur Zope, je peux donc réutiliser les vues ZPT d'une application à une autre et même d'un CPS vers un Plone par exemple.
C'est facile à réaliser (n'importe quel webdesigner avec un
minimum de connaissances en HTML sait faire)
C'est effectivement un avantage indéniable :p
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.
Encore faut-il utiliser les portlets existants.
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.
La séparation entre présentation et logique n'est-elle pas justement assurée par la séparation entre le code ZPT et le code Python ? A force de trop vouloir ajouter de couches, j'ai l'impression qu'on oublie la base.
CPSSkins est un outil utile pour faire un design lorsque l'on a aucune compétence, mais un webdesigner travaillant sur CPS n'a pas vraiment besoin de cet outil supplémentraire qui rajoute de la complexité via une nouvelle couche d'abstraction aux possibilités limitées. D'ou les questions visant à le débrancher...
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
Je viens de regarder le site, ça n'a rien à voir avec un développement commercial. Ce site est clairement un portail nuxeo "charté". Après sure qu'en incluant du _javascript_ ou du html dans des boites, on peut faire certains choses, ça reste néanmoins limité. Le header dont j'ai parlé précédement nécessite par exemple de réécrire un nouveau portlet.
_______________________________________________ cps-users-fr Adresse de la liste : [email protected] Gestion de l'abonnement : <http://lists.nuxeo.com/mailman/listinfo/cps-users-fr>
