Je viens de passer un site en zpip, le nouveau système d'organisation des gabarits proposé par Cerdic.
Le concept est d'optimiser la maintenance des gabarits en utilisant une structure unique qui va inclure des blocs de pages contextualisés.
Cela permet de mutualiser des blocs de pages sous forme d'inclures communs, tout en donnant la possibilité de contextualiser certain blocs (typiquement le contenu central de la page, et la navigation à droite).
C'est donc un gain de productivité interressant par rapport à la dist de spip, qui nécéssite de modifier tous les gabarits si on décide de changer la structure HTML du site (ajouter un bloc par exemple, ou changer de squelette).
Au passage, je trouve qu'on se rend mieux compte de la manière dont sont construites les pages, et cela permet de réfléchir mieux à ce qu'on fait.
Mais ce méchanisme butte rapidement sur un problème de diffusion des doublons, en effet, on ne peut pas par exemple semble t'il passer au bloc de navigation les doublons collectionnés dans le bloc de la page de contenu.
Avez-vous des idées pour déjouer cette limitation diabolique, qui consitue une régression vis à vis du système précédent de la dist de spip ?
Avez-vous des idées pour déjouer cette limitation diabolique,
le diable est dans les détails …
qui consitue une régression vis à vis du système précédent de la dist de spip ?
le problème existait déjà dès que tu voulais faire des inclusions
La vrai question est plutôt :
‹ est-ce que ce besoin que j’ai d’utiliser des doublons ne reflète pas un défaut d’architecture de mon information ? ›
Les doublons étant par nature contre performant en terme de requêtes, s’en débarrasser n’est pas un mal.
Cédric, qui botte en touche, limite de mauvaise foi
'est-ce que ce besoin que j'ai d'utiliser des doublons ne reflète pas un défaut d'architecture de mon information ?'
Et bien fait pour ne pas troller en l'air, voici le cas précis qui me bloque.
J'affiche dans contenu/page les résultats d'une recherche, et dans navigation/page les mots clés des articles trouvés dans la recherche sous forme de niage de tags.
Je dois donc connaitre dans le bloc navigation, le résultat de la boucle du bloc contenu.
Pour complèter la remarque de Booz concernant les doublons,
il pourrait être intéressant de faire des collections nommées dont le résultat serait stocké en base :
Ce qui donnerait, dans un squelette X :
<BOUCLE_trouves(ARTICLES){recherche truc}{collection article_trouves_truc}>
...
</BOUCLE_trouves>
{collection article_trouves_truc} se traduisant par une requete d'insertion en base (collection,id_objet,objet) pour chaque objet listé dans la collection
et dans un squelette Y
<BOUCLE_trouves(ARTICLES){dans_la_collection article_trouves_truc}>
<BOUCLE_mots(MOTS){id_article}>
</BOUCLE_mots>
</BOUCLE_trouves>
qui se traduirait par une requete de jointure (en simplifiant un tout petit peu)
JOIN spip_collections as C ON (C.id_objet=A.id_article AND C.objet='article') WHERE collection='truc'
Cela marcherait, à l'ordre des calculs près :
si Y est calculé avant X, alors on récupère la collection du coup d'avant.
(ce qui est déjà le cas avec les doublons, en moins bien, puisque on ne récupère carrément rien dans ce cas)
On pourrait alors proposer une convention bien utile :
lorsqu'un critère {dans_la_collection truc} truc est utilisé, SPIP regarde si le squelette
collection/truc.html existe,
et le cas échéant commence par le calculer si il n'est pas à jour (ce qui a pour effet de mettre a jour la collection en base de donnée)
Ceci permet de créer des collections déclarées réutilisables à plusieurs endroits d'un même site, de manière plus efficace que les doublons.
J'affiche dans contenu/page les résultats d'une recherche, et dans
navigation/page les mots clés des articles trouvés dans la recherche
sous forme de niage de tags.
Je dois donc connaitre dans le bloc navigation, le résultat de la boucle
du bloc contenu.
Sauf que tu ne sais pas dans quel ordre le thème va intégrer les deux blocs. Tel thème pourra inclure le contenu puis la navigation, tel autre thème les inclura dans l'autre sens. Du coup les doublons et !doublons ne marchent pas à coup sûr.
Le 23 novembre 2009 12:57, BoOz <booz@rezo.net> a écrit :
Je dois donc connaitre dans le bloc navigation, le résultat de la boucle du
bloc contenu.
Pour faire ce genre de bidules, j'utilise une astuce très moche: je
calcule les contenus dans la page qui inclut le gabarit...
Je m'explique, si ta page est celle de recherche, en amont tu dois
avoir un recherche.html.
Dans recherche.html tu mets ta boucle de recherche (avec un doublons
nommé ou tu stocke les id dans un #ARRAY) et la boucle qui détermine
les éléments du nuage (idem pour le doublons nommé ou l'#ARRAY.
Éventuellement tu peux stocker des pondérations pour les mots dans
l'#ARRAY). Ensuite, tu transmets les résultats au layout.html (comme
paramètres, soit les doublons, soit les #ARRAY serialisés) et donc au
bloc contenu et navigation...
Dans les blocs tu récupères les infos dans le contexte et tu n'as plus
qu'à faire des boucles d'affichage...
C'est moche, car le squelette de départ se complique salement et, ça
casse beaucoup des avantages de l'AJAX fourni avec Spip...
J'affiche dans contenu/page les résultats d'une recherche, et dans
navigation/page les mots clés des articles trouvés dans la recherche
sous forme de niage de tags.
Je dois donc connaitre dans le bloc navigation, le résultat de la boucle
du bloc contenu.
Sauf que tu ne sais pas dans quel ordre le thème va intégrer les deux blocs. Tel thème pourra inclure le contenu puis la navigation, tel autre thème les inclura dans l'autre sens. Du coup les doublons et !doublons ne marchent pas à coup sûr.
Et surtout, si on parle bien de <inclure> (?), comment tu envisagerais de gérer le contexte d'appel et la synchro des rechargement des caches ?
Non, franchement, le passage de doublons à un enfant, je vois bien, ca evite de se construire son tableau et de le passer au contexte de l'enfant, mais entre freres ou d'enfant à parent, ca n'a pas de sens.
Chaque <inclure> doit resté un morceau de programme autonome gérant son cache en fonction du contexte d'appel et du delai.
Ce qui pourrait en avoir un sens par contre, c'est de rendre accessible les doublons d'un #INCLURE à l'appelant.(puisque la le rechargement du cache est bien fait en meme temps)
Mais ca n'apporterait qu'en maintenabilité, pas en perf puisque le meme #INCLURE appelé dans 2 <INCLURE> differents ne réutilisera pas le meme cache (mais ca serait déjà pas mal de pouvoir centraliser les boucles de collecte)
Pour complèter la remarque de Booz concernant les doublons,
et le cas échéant commence par le calculer si il n'est pas à jour (ce qui a pour effet de mettre a jour la collection en base de donnée)
Ceci permet de créer des collections déclarées réutilisables à plusieurs endroits d'un même site, de manière plus efficace que les doublons.
++++++
j'attends ça depuis que j'ai commencé avec spip
Pour complèter la remarque de Booz concernant les doublons,
et le cas échéant commence par le calculer si il n'est pas à jour (ce qui a pour effet de mettre a jour la collection en base de donnée)
Ceci permet de créer des collections déclarées réutilisables à plusieurs endroits d'un même site, de manière plus efficace que les doublons.
++++++
j'attends ça depuis que j'ai commencé avec spip
Pour complèter la remarque de Booz concernant les doublons,
et le cas échéant commence par le calculer si il n'est pas à jour (ce qui a pour effet de mettre a jour la collection en base de donnée)
Ceci permet de créer des collections déclarées réutilisables à plusieurs endroits d'un même site, de manière plus efficace que les doublons.
++++++
j'attends ça depuis que j'ai commencé avec spip
si tu le dis pas, personne va le deviner ...
suis timide
les débats sur les doublons ont déja été nombreux, je crois que c'est la première fois que quelqu'un apporte une véritable nouvelle solution. et je trouve que ta proposition ouvre de nouvelles perspectives
Le 23 novembre 2009 12:57, BoOz <booz@rezo.net> a écrit :
Je dois donc connaitre dans le bloc navigation, le résultat de la boucle du
bloc contenu.
Pour faire ce genre de bidules, j'utilise une astuce très moche: je
calcule les contenus dans la page qui inclut le gabarit...
Je m'explique, si ta page est celle de recherche, en amont tu dois
avoir un recherche.html.
...
C'est moche, car le squelette de départ se complique salement et, ça
casse beaucoup des avantages de l'AJAX fourni avec Spip...
Pas bête. Mais en effet ca casse le coup de l'ajax, ce qui est dommage dans mon cas car une boucle recherche peut être assez longue à tourner, si je la mets brute de décoffrage avant d'afficher le gabarit, je rallonge le temps d'affichage de la page. Ce qui est un comble en zpip.
Le 23 novembre 2009 12:57, BoOz <booz@rezo.net> a écrit :
Je dois donc connaitre dans le bloc navigation, le résultat de la boucle du
bloc contenu.
Pour faire ce genre de bidules, j'utilise une astuce très moche: je
calcule les contenus dans la page qui inclut le gabarit...
Je m'explique, si ta page est celle de recherche, en amont tu dois
avoir un recherche.html.
...
C'est moche, car le squelette de départ se complique salement et, ça
casse beaucoup des avantages de l'AJAX fourni avec Spip...
Pas bête. Mais en effet ca casse le coup de l'ajax, ce qui est dommage dans mon cas car une boucle recherche peut être assez longue à tourner, si je la mets brute de décoffrage avant d'afficher le gabarit, je rallonge le temps d'affichage de la page. Ce qui est un comble en zpip.
Dans ton cas, si tu utilise le critère {recherche}, il n'y a aucun problème à répeter le boucle dans ta navigation.
La recherche n'est faite qu'une fois (à la première rencontre), et stockée en base ensuite. De ce fait la seconde requête est plus rapide.
Par ailleurs, si tu fais exactement la même boucle, cela produira la même requête, ce qui permet à mysql de la ressortir de son cache si il est bien réglé.
