[CPS-users-fr] CPSSkins et présentation (suite)

sebastien.masson sebastien.masson at ac-strasbourg.fr
Ven 8 Déc 18:17:30 CET 2006


Merci beaucoup pour ces réponses rapides ! Et elles en amènent 
évidemment d'autres :

>> - Il est possible de skinner en toute simplicité certaines méthodes  
>> de façon explicite (ce que j'ai fait pour index_html par exemple),  
>> mais pas des endroits particuliers du site  (une seule section par  
>> exemple); dans ce cas, il faut passer par un autre thème
>
>
> Dans les deux cas on peut se contenter de spécifier une page de thème  
> ou un couple thème/page
>
>> et faire les modifications nécessaires en ZMI,
>
>
> En effet, il n'y a pas de UI pour ça
>
C'est la technique qu'on trouve dans les tutos de JMO : la  propriété à 
retourner à  l'aide d'un script  ou d'un attribut ?
Donc, à la question "est-ce qu'on peut ... ?" je répondrai non :-)
En toute logique, avoir une page d'accueil différente du reste, une page 
de login particulière ainsi qu'une visualisation spécifique pour le 
contenu des dossiers et une autre pour le "cpsdocument_view" (ce que 
j'ai mis en place pour le moment) me semblent déjà pas mal en matière de 
souplesse !
On verra après pour les droits, histoire que les gens qui gèrent la page 
d'accueil ne soient plus admins ! Ca me fait peur parfois ...

>> (juste une précision : les portlets de contenu mis en cache  
>> répercutent-ils automatiquement les changements survenus, tels la  
>> publication ou dépublication d'un document ? Je n'ai pas encore eu  
>> trop le temps de tester ou de regarder le code).
>
>
> Normalement oui, les params de cache sont délicats à configurer, il  
> faut lire CPSPortlets/doc
>
J'avais prévu de le faire de toute façon, il y a de la lecture 
visiblement ! Et le concept semble intéressant, ça vaut le coup de s'y 
pencher. Mais si ça se gère bien, je crois que ça va me sauver la vie :  
quand un grand manitou (comprenez : quelqu'un avec beaucoup de droits 
assez haut dans l'arborescence) arrive sur cette belle liste de 
plusieurs centaines de workspaces, le serveur n'apprécie pas trop la 
visite !

>>
>> - L'apparence des portlets est liée à la façon dont les styles sont  
>> définis pour les slots qui les contiennent; il n'est pas possible  
>> d'avoir plusieurs portlets (des listes de contenu par exemple)  
>> d'apparence différente dans un même slot.Il n'y a pas de notions  
>> d'apparence qui leur soit attachée de façon individuelle.
>> Si on cherche à avoir un rendu un peu "sapin de Noël", du genre  
>> trois listes de contenu utilisant le même "moteur" mais avec des  
>> puces et des polices différentes, il    faudra  créer autant de  
>> slots  que de styles prévus; donc l'avoir prévu à l'avance et ne  pas 
>> le remettre en question sans cesse.
>> Si je pose cette question, c'est qu'actuellement - sur une version  
>> ancienne - j'ai au moins six déclinaisons de la boîte de contenu  par 
>> défaut mais chacune avec des puces, couleurs, polices, ou  tableaux 
>> différents, en fonction des envies de gens influents.  J'aimerais 
>> bien pouvoir leur donner les même possibilités mais sans  avoir à 
>> dupliquer du code bêtement ou les obliger à trop réfléchir  quant à 
>> l'organisation des thèmes et des slots stylisés, histoire  qu'ils 
>> soient autonomes et ne me fassent pas faire des choses  redondantes 
>> sans cesse.
>
>
> On peut s'en sortir, mais c'est nettement plus chaud:
>
> Comme vous avez l'air courageux, vous pouvez faire des portlets de  
> contenu à base de CPSDashboards, mettre des classes CSS sur les  
> widgets rendant chaque élément et ainsi décliner plusieurs types de  
> portlets à mettre dans le même slot. Il suffit de reprendre ces  
> classes dans un custom.css. Ça casse un peu la séparation logique/ 
> présentation, mais ça marche. On peut même faire des choses dans ce  
> genre (non précis):
>      div.monStyleDeBoiteCPSSkins (...éléments intermédiaires...)  
> div.lePortletDeMonBoss { 'color' : red;}
> pour continuer à décliner en plus suivant la boîte qui contient tout ça.
>
> Mais c'est un sacré travail (un type de portlet à chaque sous-style),  
> bien comprendre ce qui se passe...
>
>
Je m'en doute, finalement c'est du même acabit que mes boîtes clônées, 
en plus propre ! Il va falloir que je fasse de la pédagogie, expliquer 
aux gens qu'on pense rendu ou contenu à des moments différents ! (et 
qu'ils feraient bien de penser davantage au second plutôt qu'au premier!).

Dans le même ordre d'idée, j'ai une autre question concernant les 
documents cette fois-ci : on me demande souvent un moyen de faire en 
sorte que les documents puissent avoir un rendu différent mais tout en 
restant du même type (surtout pour les Flexibles, qui sont je l'avoue 
une belle trouvaille). Le problème, c'est qu'on a bien la possibilité de 
modifier le css au niveau du widget, mais ce n'est pas accessible pour 
l'utilisateur ou alors nécessiterait une modification globale.
Est-ce que l'idée de repartir sur un nouvel ensemble de schemas/layouts 
inspirés de ceux associés aux Flexible, mais proposant un champ "style" 
par exemple( que l'on pourrait alimenter à l'aide d'un vocabulaire, ou 
d'un textarea contenant sa définition) et qui ferait partie du DataModel 
lors de la génération du rendu vous semble incongrue ? Ou alors, 
existe-t-il un moyen plus "CPSish" de faire cela ?
Il me restera ensuite à ajouter, sur le même principe, la possibilité de 
définir une cible explicite sur les liens (user configurable, bien 
entendu) pour faire bien des heureux !

Toutes ces modifications, c'est bien joli, mais une question cruciale 
demeure : comment répercuter les changements de layouts/schemas sur les 
documents déjà existants ? Il me semble que certaines upgrades sur 
d'anciennes versions faisaient ça, pour la prise en compte de 
nouveautés, mais je n'arrive plus à retrouver où et comment c'était 
fait. Auriez-vous un tuyau ?

Désolé si ces questions semblent parfois un peu bêtes, mais je n'ai pas 
toujours le temps de démonter tout le fonctionnement de CPS dans ses 
détails pour savoir si ce que je cherche existe déjà (et donc mieux fait 
que ce que je pourrais bricoler moi-même) ou doit être créé 
spécifiquement; parfois les docs m'apportent de quoi pousser mes 
investigations plus loin, parfois je sèche complètement.Quand je vois 
certaines de mes horreurs des débuts (et même sous CPS2), j'aimerais 
mieux "rester dans la norme" autant que possible !
Pour l'essentiel, on a tout ce qu'il faut sous la main en matière de 
paramétrage, mais parfois c'est un peu délicat, surtout pour des sites 
qui ont plus de trois ans d'âge et la masse de contenu qui va avec, avec 
des décideurs qui ont changé et qui remettent pas mal de choix initiaux 
en question !

Merci d'avance.

SM



Plus d'informations sur la liste de diffusion cps-users-fr

This list archive provided by Nuxeo, the leaders of open source ECM. Check out the Nuxeo 5 open source, standards-based ECM project.