Bonjour,
J'ai l'impression d'avoir trouvé un bug, mais qui semble dépendre du
serveur sur lequel SPIP (la même version) est installée... C'est pourquoi
j'ai quelques doutes, mais bon. Vous serez seuls juges :
En SPIP 2.0 (stable, branche 2.0 SVN [14047]), j'utilise la base locale
de SPIP et une base externe, qui n'est pas au format SPIP (nommée B dans
l'exemple).
Dans un squelette, dans une boucle faisant appel à la base B, j'inclus un
squelette qui contient une boucle SPIP simple (sans appel à une base
externe) :
Squelette principal :
<BOUCLE_items(B:items){tout}>
<INCLURE{fond=squelette-inclus} />
</BOUCLE_items>
squelette-inclus.html :
<BOUCLE_rubriques(RUBRIQUES){id_rubrique=2}>
Bla bla
</BOUCLE_rubriques>
Et ben ça ne marche pas ; le message d'erreur affiché est :
Table SQL « B:rubriques » inconnue
Si je remplace RUBRIQUES par connect:RUBRIQUES, ça marche en revanche.
Question : est-ce que le nom de la base utilisée est héritée dans la
boucle ? Je précise que si je n'utilise pas de squelette inclus, ça
fonctionne comme prévu avec RUBRIQUES (sans le connect: ).
Ce qui est curieux, c'est que sur l'un des serveurs de test, ça
fonctionne. C'est pourquoi je présume qu'il y a plusieurs causes (et pas
seulement une cause dans SPIP).
Est-ce que vous observez le même comportement ? Est-ce qu'il est normal
(et dans ce cas il FAUT le connect: dans la boucle du squelette inclus) ?
Merci !
Amicalement,
Bonjour,
Ce comportement a été modifié dans un commit récent : la base est héritée dans les inclusions.
Avant, la base etait transmise par #INCLURE mais pas par <INCLURE>
Elle l'est maintenant toujours, automatiquement.
Mais tu peux specifier la base explicitement en faisant
<INCLURE{fond=squelette_inclus}{connect=xxx}>
donc ici {connect=connect}
La version de ton spip qui ne te pose pas de problème doit être légèrement plus ancienne.
Cédric
cedric.morin@yterium.com a écrit :
Ce comportement a été modifié dans un commit récent : la base est
héritée dans les inclusions.
Avant, la base etait transmise par #INCLURE mais pas par <INCLURE> Elle
l'est maintenant toujours, automatiquement. Mais tu peux specifier la
base explicitement en faisant
<INCLURE{fond=squelette_inclus}{connect=xxx}>
donc ici {connect=connect}
La version de ton spip qui ne te pose pas de problème doit être
légèrement plus ancienne.
C'était bien ça !
Merci beaucoup pour la réponse rapide.
Je ne trouve pas ce fonctionnement très intuitif, parce qu'il va falloir
faire gaffe lors de l'inclusion des squelettes, selon l'endroit où elle
est faite (alors que je trouvais logique que ce soit le squelette inclus
qui choisisse la base sur laquelle faire les requêtes, surtout dans le
cas de multiples bases avec différents formats). C'est pas un souci, vu
qu'il y a des solutions de contournement 
Amicalement,
Trois Singes a écrit :
cedric.morin@yterium.com a écrit :
Mais tu peux specifier la
base explicitement en faisant
<INCLURE{fond=squelette_inclus}{connect=xxx}>
donc ici {connect=connect}
Je ne trouve pas ce fonctionnement très intuitif,
Ah tiens, là sur ce coup là, moi non plus !
Je trouvais vraiment bien qu'on puisse enfin passer {connect=qqc} via <INCLURE> mais j'avais pas tilté que ça prenait par défaut le connect en cours...
Je crois que ce qui me chagrine, c'est qu'on peut vouloir passer le connect "par défaut" à l'<INCLURE> mais celui-ci ne s'appelle pas forcément "connect" (chez moi ils portent le nom du site), du coup, ça risque de créer des squelettes pas très génériques... Bon, c'est du détail...
{connect=''}
doit faire l'affaire aussi pour le connect par defaut
Cédric
{connect=''}
doit faire l'affaire aussi pour le connect par defaut
Normalement quand tu fais une inclusion tu ne passes pas de paramètre
: autrement dit le résultat d'une inclusion ne dépend que de la façon
dont elle est appelée. J'ai introduit une première déviation pour
passer la langue courante par défaut, parce qu'on passait
systématiquement {lang} tous les squelettes. Le connect est donc la
deuxième déviation, mais je trouve qu'elle se justifie moins.
-- Fil
En fait, #INCLURE passait le connect automatiquement et pas <INCLURE>, et on ne pouvait pas le passer en parametre manuellement.
J'ai homogénéisé, en rendant le passage automatique par défaut, et du coup rendu possible aussi le passage manuel par surcharge
Je ne suis pas un gros utilisateur, et j'ai même été obligé de prévoir une dérogation pour ne pas passer pour et condition.
Donc en ce qui me concerne, je suis aussi pour ne pas mettre de passage auto de connect, mais laisser possible le passage manuel.
Si ça vous va, donc, je corrige comme cela, ça enlevera donc un comportement déviant, et la gestion de la dérogation à la déviance.
Cédric