Thierry Florac a écrit :
Le mercredi 01 octobre 2008 à 01:02 +0200, Christophe Combelles a
écrit :
Tout d'abord bravo pour ce site, c'est un gros boulot, et le résultat est impressionnant !

Merci :-)
Ça a effectivement été un (très !) gros boulot, et ce n'est pas fini !
La suite risque d'être assez cool aussi si on arrive à faire tout ce
qu'on veut...
Et comme déjà évoqué, j'aimerais profiter de cette expérience pour faire
un peu de buzz autour de Zope3 et montrer, aussi bien à des développeurs
que des décideurs, que Python et Zope3 peuvent tout à fait être utilisés
dans le cadre de sites web complexes gérant des contenus volumineux.
Mais je ne sais pas encore ni où ni comment présenter la chose...
On va d'ores et déjà demander à l'un de nos prestataires de faire une
étude comparative pour évaluer le coût de développement de notre site,
compte tenu des contraintes techniques et des fonctionnalités mises en
oeuvre, avec une solution traditionnelle (type PHP ou Java) ; j'attends
le résultat avec impatience...


Une URL plus logique (et meilleure pour l'indexation) pour cette page aurait 
été:
http://www.onf.fr/activites_nature/evenements/animations-ecoute-du-brame

"evenements" étant un conteneur, "animations-ecoute-du-brame" un objet événement, et la vue étant implicitement "@@index.html".

Mais tout dépend la façon dont sont stockés les choses.
Par ex, je ne comprends pas bien pourquoi tu récupères l'article par une recherche d'oid dans le catalogue, s'il suffit de le récupérer par sa clé dans un conteneur, la clé étant le truc visible dans l'url, débarassé des accents (ça porte un nom, j'arrive plus à me souvenir).

Sinon, à quoi sert l'id de conf ?
?conf_id:int=1219820993
Est-ce que ça a un intéret de le transmettre par l'URL ? Est-il susceptible de changer pour la même URL ?

Pourquoi pas un utility qui fournit cette conf ?

Le site au sein duquel est affichée cette vue est important puisqu'il
détermine, notamment, le skin qui va être appliqué ; il ne me paraît
donc pas possible de simplement travailler avec une vue dans le contexte
de l'actualité sans tenir compte de ce paramètre.
À mon avis si, l'objet que tu est en train de publier n'est pas le "site" activites_nature, mais bien l'article « écoute du brame ». C'est donc l'article qui devrait être le contexte.

Pour changer l'apparence juste dans le site activites_nature, tu peux utiliser un beforeTraverseEvent sur le site, qui va rajouter la bonne layer dans ta request, et donc modifier la skin uniquement pour ce site.

Mais sinon, puisque c'est un "site", ça veut dire qu'il a un registre local, et donc que tu peux faire des inscriptions locales et donc potentiellement tout changer.

Sinon avec z3c.template/z3c.pagelet, y a moyen de faire un lookup du template de layout (z3c:layout en zcml), donc on peut le changer précisément ou on veut. Moi je n'utilise plus que ça, c'est ce que j'ai trouvé de plus souple.

Mais bon, faudrait que je connaisse un peu mieux les détails.


Je suis tout à fait d'accord avec toi de A à Z compte tenu des éléments
dont tu disposes ; ta première approche au niveau de la gestion des URLs
est tout à fait pertinente mais comme tu le dis dans ta dernière phrase,
il te manque sans doute quelques billes que je vais tenter
d'éclaircir...
Désolé pour la longueur du propos !!

c'est long, mais j'ai fini par le lire en entier :)
C'est une problématique intéressante.


Tout d'abord, le "site" dont je parle n'est pas un site au sens "Site
Manager" de Zope 3 ; c'est juste le premier niveau de l'arborescence de
notre portail. Le seul "site" (au sens Zope 3) est défini à la racine.

Pour essayer de comprendre un peu mieux mon problème, le portail est
donc structuré autour de deux types d'informations :
 - des informations "de base", intégrées dans des "sites" (au sens de
notre portail) selon une structure arborescente : sites, rubriques,
sous-rubriques, sujets, articles
 - des informations complémentaires et "partagées", stockées dans des
conteneurs dédiés et en dehors des sites : actualités, galeries
d'images, références commerciales, interviews, compléments, communiqués
de presse...

Toutes ces informations sont thématisées, géolocalisées et porteuses de
ce que l'on appelle une audience qui indique à qui elles sont destinées
(grand public, professionnels, journalistes...), avec quelle portée
géographique (département(s), région(s), France entière, autres pays) et
éventuellement avec quelles restrictions d'accès (pour certaines
informations qui seront réservées aux abonnés).
Dans le cas des informations partagées, ces paramètres vont nous
permettre de "diffuser" ces informations dans différents endroits du
portail.

La navigation se fait uniquement au sein des sites ; ce qui signifie que
quelle que soit l'information que l'on consulte, on est toujours
"visuellement" dans le contexte d'un site (ou de la home qui peut être
considérée comme un site particulier dans ce cas).
Pourquoi est-ce important ? Parce que toutes les pages de consultation
des sites sont construites sur la base d'un assemblage de composants,
chaque composant étant dédié à un type de contenu particulier.
Dans mon exemple, je vais par exemple configurer dans le contexte du
site "activités nature" un composant chargé de récupérer une liste
d'actualités (celui que l'on peut voir en haut à droite) ; ce site est
un site "grand public", de niveau national, portant sur le thème
"activités nature", et on va donc paramétrer le composant "actualités"
pour qu'il nous affiche des actualités définies avec les mêmes
paramètres ; d'autres composants pourraient être paramétrés pour
extraire d'autres contenus, dans le même contexte, selon des critères
identiques ou non.

Là ou la difficulté se fait jour (selon moi) : lorsque j'accède par
exemple à une actualité, elle doit s'afficher comme un "post-it" dans le
contexte de mon site de départ : le fil d'Ariane n'est pas modifié, la
charte graphique est celle de ce site (ça, c'est simple à gérer, comme
tu l'indiques, avec un beforeTraverseEvent, ce qui est déjà le cas), et
surtout :
 - le contenu des colonnes gauche et droite est celui correspondant au
paramétrage de mon contexte de départ
 - les fonctions de navigation proposées au sein de mon actualité
doivent bien entendu correspondre au contenu de mon composant
"actualités" de départ ; comme une actualité donnée peut, en fonction
des différents paramètres dont elle est porteuse, être consultée dans le
contexte de différents sites (par exemple, une actualité d'intérêt
national traitant d'activités nature en Lorraine sera visible à partir
du site activités nature mais aussi du site de la Dt Lorraine), il ne
faut pas se mélanger les pinceaux ! Et si je navigue d'une brève à
l'autre et que je referme le "post-it", je dois bien évidemment revenir
à mon contexte initial.

D'accord je crois que je comprends, c'est un peu comme si tu avais plusieurs contextes en meme temps. Le premier provient du path, c'est le contexte naturel de la vue, et l'autre est transmis en GET.


Voilà donc pourquoi aujourd'hui je transmets ce fameux "conf_id" dans
mon URL, pour indiquer quel est le composant dont je suis parti pour
afficher mon actualité ; car pour certains types de composants, il est
tout à fait possible d'avoir dans une même page le même composant
présent plusieurs fois avec des configurations différentes. L'exemple
est débile mais si j'avais deux listes d'actualités dans une même page,
avec une même actu affichée deux fois, il faudrait bien que les
fonctions de navigation liées à l'affichage de cette actu correspondent
au composant dont on est parti pour l'afficher.

ca se tient.


Il reste encore quelques autres subtilités liées à la gestion de ces
composants (avec notamment des notions d'héritage de configuration entre
niveaux de l'arborescence, des niveaux de paramétrage différents, une
gestion de "cache de résultats" par composant pour limiter les
recherches...) mais je ne crois pas que cela modifie le fond du
problème...

la vache, t'as l'air de t'être amusé.


Voilà, j'espère avoir été plus clair sur le pourquoi du comment de mes
petits soucis de gestion d'URLs. Donc si vous avez plus d'idées pour
m'aider à résoudre ce problème (assez mineur en fait au final, il s'agit
juste de "faire de jolies URLs"), je suis toujours preneur !

Faut pas culpabiliser forcément avec les urls. Les paramètres GET doivent bien avoir une utilité de temps en temps. Ce qui est gênant, c'est que c'est pas tres restful : l'actualité en tant que document n'a pas sa propre URL, alors qu'elle représente un contenu bien particulier. Ou sinon, dans ce cas, tu pourrais faire de l'ajax pour afficher le post-it.

Si on reprend l'exemple:
http://www.onf.fr/activites_nature/evenements/animations-ecoute-du-brame
on pourrait imaginer que "evenements" n'est pas un dossier persistant,
mais juste un dossier de traversing, un peu comme ++etc++site, qui te mène vers le vrai dossier des actualités, et qui fonctionnerait aussi bien dans le site "activite_nature" qu'un autre site. (d'ailleurs tu pourrais l'appeler ++actu++, ça ferait zope3 à fond :) ) Sinon il y aurait toujours éventuellement des paramètres de conf transmis dans l'URL, mais ils ne devraient pas être indispensables à la visualisation de la news.

Mais bon, encore une fois faut pas culpabiliser : tu as atteint ton but en ayant des contraintes complexes, c'est le principal. Et ça n'a pas l'air de gêner pour l'indexation :
http://www.google.com/search?q=%22Qui+est+le+sanglier%22

Christophe

PS : il est assez réactif, le site, en plus.

_______________________________________________
zope3-french-user mailing list
zope3-french-user@lists.afpy.org
http://lists.afpy.org/mailman/listinfo/zope3-french-user

Répondre à