[SPIP Zone] À propos de cfg et cvt

Pierre_FICHES · Mai 17, 2009, 11:23

Bonjour,

Soit un fonds cfg qui appelle deux formulaires cfg en cvt.
Le chargement des champs du second dépendent du premier.

J'obtiens bien le résultat escompté si le premier n'est pas appelé en ajax.

Après enregistrement du premier formulaire, les champs adéquat du second sont chargée avec leur valeurs par défaut calculées.

Mais...

... la fonction vérifier ne veut rien savoir, elle ne vérifie pas et le formulaire n'est pas enregistré.

Est-ce un bug ou mon code qui va pas ?

Pour que vérifier fonctionne je suis obligé de faire (dans le formulaire html) :

[(#ENV{defaut_w_c2}|non)</ul><ul style="display:none;">]

[(#SAISIE{input, w_c2}{defaut=#ENV{defaut_w_c2}}
{label=Largeur de la colonne deux}
{explication=Indiquer la largeur en % sans le spécifier.}
)]

Alors que je voulais :

[(#ENV{defaut_w_c2}|oui)

[(#SAISIE{input, w_c2}{defaut=#ENV{defaut_w_c2}}
{label=Largeur de la colonne deux}
{explication=Indiquer la largeur en % sans le spécifier.}
)]

]

Autrement dit, pour la fonction verifier, qu'est qui est similaire à [(#ENV{w_c2}|oui)] qui marche bien pour la fonction charger ?

Catherine_Ossakowsky · Mai 17, 2009, 11:34

Bonjour,

Ca fait une semaine que je me torture sur le fonctionnement de la recherche native de SPIP et je ne trouve pas de rponse.

Suis tente de croire que c’est un bug mais a me semble un peu gros ( et je suis un peu trop dbutante sous spip pour oser affirmer ce genre de choses).

Expos du problme :

La recherche sur plusieurs mots donne des rsultats eronns.

Version installe la 2.0.8 (sous apache 2.xx et php 5.xx qui va bien) sous Wamp en local.

Conditions du tests :

Je cre une rubrique et un article qui s’appelle par exemple « la petite maison dans la prairie ».

Je fais une recherche de petite maison l’article est trouv.

Je fais une recherche de maison petite aucun article.

Sur les mots clefs (configuration avance), bizarre aussi si j’associe deux mots clefs mon article, et que je cherche les deux par la fonction recherche native, aucun article n’est trouv. Alors qu’une recherche un par un ressort cet article.

Avec les mmes tests (mme env. etc…) mais sous la 1.9.2(f!) tout va bien, quelque que soit la recherche.

C’est donc une question sur la base de SPIP, a m’ennuie je commence dvelopper le site, et c’est inquitant qu’un lment de base comme celui l ne fonctionne pas bien.

Malgr mes longues et fastidieuses recherches sur le net, je ne trouve personne qui relve cette anomalie.

(n.b.: j’ai du rinstaller spip une bonne dizaines de fois pour tre bien sr que a ne venait pas de a).

Si quelqu’un a un ide voir ou confirme qu’il y a un soucis, je le remercie d’avance;

Merci

Catherine Ossakowsky

cerdic · Mai 18, 2009, 5:10

Bonjour,
cela correspond bien au fonctionnement natif de la recherche de SPIP.
Ce n’est pas un problème de structure de BDD, mais un problème de compromis coût/performance du moteur de recherche.
Les solutions de moteur de recherche libre ne sont pas légion, et c’est donc un sujet qui reste ouvert.
Cela dit, si tu as des exigences un peu plus élevées que le fonctionnement de base,
http://www.spip-contrib.net/Fulltext
sera sûrement ton ami.

Cédric

Le 18 mai 09 à 01:34, Catherine Ossakowsky a écrit :

Bonjour,

Ca fait une semaine que je me torture sur le fonctionnement de la recherche native de SPIP et je ne trouve pas de rponse.

Suis tente de croire que c’est un bug mais a me semble un peu gros ( et je suis un peu trop dbutante sous spip pour oser affirmer ce genre de choses).

Expos du problme :

La recherche sur plusieurs mots donne des rsultats eronns.

Version installe la 2.0.8 (sous apache 2.xx et php 5.xx qui va bien) sous Wamp en local.
Conditions du tests :
Je cre une rubrique et un article qui s’appelle par exemple « la petite maison dans la prairie ».

Je fais une recherche de petite maison l’article est trouv.
Je fais une recherche de maison petite aucun article.

Sur les mots clefs (configuration avance), bizarre aussi si j’associe deux mots clefs mon article, et que je cherche les deux par la fonction recherche native, aucun article n’est trouv. Alors qu’une recherche un par un ressort cet article.

Avec les mmes tests (mme env. etc…) mais sous la 1.9.2(f!) tout va bien, quelque que soit la recherche.

C’est donc une question sur la base de SPIP, a m’ennuie je commence dvelopper le site, et c’est inquitant qu’un lment de base comme celui l ne fonctionne pas bien.

Malgr mes longues et fastidieuses recherches sur le net, je ne trouve personne qui relve cette anomalie.

(n.b.: j’ai du rinstaller spip une bonne dizaines de fois pour tre bien sr que a ne venait pas de a).

Si quelqu’un a un ide voir ou confirme qu’il y a un soucis, je le remercie d’avance;

Merci

Catherine Ossakowsky

spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone

19eb0d0ad6f2ebee089f · Mai 18, 2009, 10:16

Pierre Fiches a écrit :

Alors que je voulais :

[(#ENV{defaut_w_c2}|oui)
[(#SAISIE{input, w_c2}{defaut=#ENV{defaut_w_c2}}
{label=Largeur de la colonne deux}
{explication=Indiquer la largeur en % sans le spécifier.}
)] ]

C'est un problème de compréhension du fonctionnement de CFG qui fait que ça ne fait pas ce que tu attends :

1) CFG fait une compilation du squelette SANS passer d'environnement et étudie le résultat :
2) Sur ce résultat, CFG lit les parametres  ainsi que les champs de formulaire dont il récupère tous les name="yy".
3) Avec ces deux données (paramètres + champs), CFG calcule les valeurs d'environnement (le contexte de compilation) attendu par le concepteur du formulaire...
4) CFG compile le squelette AVEC le contexte de compilation calculé, puis l'affiche.

5) Quand tu valides, CFG fait alors les traitements seulement s'il y a des changements : pour cela, il refait 1) 2) et 3) puis récupère tous les champs calculés connus qui ont été envoyés. S'il y a des changements, CFG lance la fonction "traiter", sinon indique "Pas de changement".

6) La fonction traiter écrit les nouvelles valeurs à l'endroit demandé par le concepteur

7) Réaffichage du formulaire comme au début (donc 1 à 4)

---

Dans ton cas, si tu mets :
[(#ENV{defaut_w_c2}|oui)
#SAISIE...
]

Lorsque CFG fait (1), la saisie n'est pas affiché car (#ENV{defaut_w_c2}) n'est pas présent dans l'environnement. Par conséquent, dans (2), CFG n'a pas connaissance du champ présent dans la saisie... Il ne cherchera donc pas au moment de la validation à la récupérer... Si tu ne changes que le contenu de cette saisie dans le formulaire, CFG te dira donc "Pas de changement"...

La seule possibilité que tu as de pouvoir faire cela, c'est de ne pas utiliser pour tes tests ENV, mais la balise CONFIG qui va calculer le champ (par contre, ça prend un peu plus de ressources).

[(#CONFIG{plugin/casier/defaut_w_c2}|oui)
#SAISIE...
]

--
MM.

Catherine_Ossakowsky · Mai 18, 2009, 11:25

Euh…

Merci pour la réponse, mais je crois que trouver les articles contenant deux mots (où qu’ils soient titre ou texte) quel que soit l’ordre dans lequel on les a indiqué dans le formulaire de recherche me semble faire partie du minimum qu’on peut demander à un moteur de recherche non ? Par ailleurs, dans les documentations de SPIP, il est indiqué que le moteur devrait retourner les articles dans ce cas là. (pondération par présence de mots dans les différentes parties de l’article.)

En tout cas, ça fonctionnait sur la version 192, et ça ne fonctionne plus sur la 208.

D’autres avis ?

PS : j’ai testé le plugins fulltext qui ne corrige pas le problème.

Catherine Ossakowsky

GSM : 06 98 80 66 00

De : cedric.morin@yterium.com [mailto:cedric.morin@yterium.com]
Envoyé : lundi 18 mai 2009 07:10
À : Catherine Ossakowsky
Cc : spip-zone@rezo.net
Objet : Re: [SPIP Zone] Question de débutant : bug de la fcontion rechercher

Bonjour,

cela correspond bien au fonctionnement natif de la recherche de SPIP.

Ce n’est pas un problème de structure de BDD, mais un problème de compromis coût/performance du moteur de recherche.

Les solutions de moteur de recherche libre ne sont pas légion, et c’est donc un sujet qui reste ouvert.

Cela dit, si tu as des exigences un peu plus élevées que le fonctionnement de base,

http://www.spip-contrib.net/Fulltext

sera sûrement ton ami.

Cédric

Le 18 mai 09 à 01:34, Catherine Ossakowsky a écrit :

Bonjour,

Ca fait une semaine que je me torture sur le fonctionnement de la recherche native de SPIP et je ne trouve pas de rponse.

Suis tente de croire que c’est un bug mais a me semble un peu gros ( et je suis un peu trop dbutante sous spip pour oser affirmer ce genre de choses).

Expos du problme :

La recherche sur plusieurs mots donne des rsultats eronns.

Version installe la 2.0.8 (sous apache 2.xx et php 5.xx qui va bien) sous Wamp en local.

Conditions du tests :

Je cre une rubrique et un article qui s’appelle par exemple « la petite maison dans la prairie ».

Je fais une recherche de petite maison l’article est trouv.

Je fais une recherche de maison petite aucun article.

Sur les mots clefs (configuration avance), bizarre aussi si j’associe deux mots clefs mon article, et que je cherche les deux par la fonction recherche native, aucun article n’est trouv. Alors qu’une recherche un par un ressort cet article.

Avec les mmes tests (mme env. etc…) mais sous la 1.9.2(f!) tout va bien, quelque que soit la recherche.

C’est donc une question sur la base de SPIP, a m’ennuie je commence dvelopper le site, et c’est inquitant qu’un lment de base comme celui l ne fonctionne pas bien.

Malgr mes longues et fastidieuses recherches sur le net, je ne trouve personne qui relve cette anomalie.

(n.b.: j’ai du rinstaller spip une bonne dizaines de fois pour tre bien sr que a ne venait pas de a).

Si quelqu’un a un ide voir ou confirme qu’il y a un soucis, je le remercie d’avance;

Merci

Catherine Ossakowsky

spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone

klaus · Mai 28, 2009, 2:36

Merci de nous dire qu'on n'est pas les seuls à galérer pendant des heures

Ton résumé risque de bientôt me dépanner.

klaus++

Fil schrieb:>

Le problème : dans la base de données DATABASE,
certaines tables ont des problèmes de charset, *mais pas toutes*.

Comment savoir si la table a un problème :

mysql -u(USER) -p(PASSWORD) DATABASE
SELECT titre FROM spip_articles LIMIT 10;

==> "Les petits mÃ©tiers clandestins"

ici on devrait avoir un "é" et pas "Ã©".

Pour résoudre ça, SPIP propose un outil de conversion efficace :
?exec=convert_sql_utf8

Une fois cette conversion appliquée, j'ai constaté que trois tables de
la base étaient en fait *doublement* en utf8, c'està-dire que le é,
qui en binaire s'écrit Ã©, est devenu (en binaire toujours), "ÃCÂ©",
qui correspond à la conversion utf8 de la chaine iso "Ã©". Donc 4
caractères en binaire, alors qu'il en faut deux. Du coup après
conversion, les tables en question se retrouvaient à afficher des
"Ã©". Vous me suivez ?

Ces trois tables : spip_articles, spip_auteurs, spip_mots : sans doute
lié à notre méthode d'importation initiale des données.

J'ai fait un dump de ces tables en précisant que je voulais un
dump "latin1", histoire d'avoir (en binaire) dans mon fichier dump la
chaîne "Ã©".
# mysqldump --opt --default-character-set=latin1
DATABASE spip_articles spip_auteurs spip_mots >
latin1.sql

Ensuite dans le dump (latin1.sql) j'ai remplacé (avec un éditeur de
texte tout bête) la chaîne :
/*!40101 SET NAMES latin1 */;
en
/*!40101 SET NAMES utf8 */;

puis j'ai réimporté le fichier dump.
# mysql DATABASE < latin1.sql

En important ce fichier MySQL a lu "Ã©" comme étant bien le
caractère "é" en utf8.