Pour une feature qui est vendue au départ comme plus légère en code que de regarder les zones de l’auteur, c’est la bérézina…
Je ne suis pas d’accord du tout pour valider l’appel a trouver_table dans chaque hit, il faut être un peu plus smart.
En l’occurence, la liste des zones accessible a tous les utilisateurs non connectés est une liste finie et permanente, qui ne change presque jamais et qui ne dépend pas de l’auteur connecté.
Est-ce qu’on peut la cacher dans les meta ?
De préférence en la gérant depuis un pipeline post_edition qui l’update a chaque modif du champ concerné pour une zone ?
Pour une feature qui est vendue au départ comme plus légère en code
que de regarder les zones de l'auteur, c'est la bérézina...
Je ne suis pas d'accord du tout pour valider l'appel a trouver_table
dans chaque hit, il faut être un peu plus smart.
Bonjour,
j'ai suivi avec intéret l'annonce de Rasta (car il s'agit AMHA d'une
facilité simple complémentaire à Accès Restreint
(qui me manque) et plus sure/plus complète qu'Intranet/Extranet...
mais le problème de performance est effectivement un souci... (meme si
ce n'etait que'au pré-compilateur !!)
En l'occurence, la liste des zones accessible a tous les utilisateurs
non connectés est une liste finie et permanente, qui ne change presque
jamais et qui ne dépend pas de l'auteur connecté.
Est-ce qu'on peut la cacher dans les meta ?
De préférence en la gérant depuis un pipeline post_edition qui
l'update a chaque modif du champ concerné pour une zone ?
Mais ma réflexion est un peu différente.... d'où l'idée ci-après :
car en l'occurence la "complexité" correspond à un cas d'erreur SPIP (et
-j'ai pas revu- uniquement pour les Admins/Webmestres?..)
or j'ai souvenir de nombreux "affichages petés" (pour des problèmes de
cache incompletement recalculés..)
Ma question porte sur le fonctionnement de SPIP en cas d'erreurs : "vu
de loin" !!
le traitement des erreurs est disséminé dans le code ; ne serait-il pas
possible de l'échapper (genre Try / Exception)
et de le gérer par un pipeline commun ;
- ainsi il suffirait à la modif de Rasta de désactiver cet affichage
pour ne pas poser de souci d'affichage...
Deuxieme idée, et plutot "demande" : l'approche de Cedric sur le
filtrage d'Accès Restreint m'avait séduit par la démarche "native" à la
source de données : or je me rends compte que ce besoinde
filtrage-source peut arriver souvent !
Il me semble qu'il est possible de rajouter des filtrages sur le meme
principe (entre le {tout}, {tout_voir} etc..), et ce besoin me sembre
frequent,
ne serait-ce que pour presenter des contenus spécifiques en fonction
du statut ou du contexte personnel d'un visiteur authentifié sans devoir
intervenir sur tous les squelettes (c'est déja assez à gérer pour de
nombreux webmestre) ;
j'aimerais comprendre/donc proposer ensuite un "mode d'emploi"
opérationnel pour rajouter ces filtrages
par un plugin : juste un exemple d'application possible,
- montrer les articles et contenus de l'année ou d'une année antérieure
sur une option de préférence personnelle)
Je prends conscience que cela amenerait peut-ete a considerer la
structure de filtrage SQL d'accès-restreint comme une primitive d'entrée
sur la base de données SPIP (et objets editoriaux complémentaires) qui
pourrait alors proposer uen API complémentaire /analogue à l'API autoriser ?
Ensuite une simple extension de configurer_filtre_perso dans les
préférences, ou dans tout autre CFG,
Et cela s'applique directement.... /plus besoin de rajouter
mes_favoris.../
Qu'en pensez-vous (je ne maitrise pas assez le code d'Accès Restreint
pour approfondir techniquement..)
Peut-etre me repondrez-vous qu'il existe déjà un pipeline qui peut
injecter automatiquement ces filtrages lors de la compilation ou
l'exécution des squelettes ?
Est-ce qu'on peut la cacher dans les meta ?
De préférence en la gérant depuis un pipeline post_edition qui l'update
a chaque modif du champ concerné pour une zone ?
C'est super oui, et donc voilà :
Il n'y a donc plus aucune requête (même pour la meta puisqu'on la prend dans GLOBALS).
Pour le trouver_table, ce n'était même pas un truc utile, mais obligé, car c'était pour ne pas avoir l'erreur tant qu'on avait pas encore été mettre à jour le plugin (et si on était admin on pouvait même pas mettre à jour puisque ça affichait var_mode=debug partout, masquant ce qu'il y a dessous, à cause du champ manquant tant que c'était pas fait).
Bref c'était pourri ouais…
Est-ce qu'on peut la cacher dans les meta ?
De préférence en la gérant depuis un pipeline post_edition qui l'update
a chaque modif du champ concerné pour une zone ?
Il n'y a donc plus aucune requête (même pour la meta puisqu'on la prend
dans GLOBALS).
Pour le trouver_table, ce n'était même pas un truc utile, mais obligé,
car c'était pour ne pas avoir l'erreur tant qu'on avait pas encore été
mettre à jour le plugin (et si on était admin on pouvait même pas mettre
à jour puisque ça affichait var_mode=debug partout, masquant ce qu'il y
a dessous, à cause du champ manquant tant que c'était pas fait).
Bref c'était pourri ouais…
