Faire un tri a partir d'un formulaire

[docanski]

Bonsoir,

J'envisage de créer un outil de détermination (et donc de recherche) au
départ d'un formulaire.
Ce dernier, situé à http://mycorance.free.fr/valchamp/mycdeter.html ,
devrait aboutir par l'intermédiaire d'un script PHP (faisant le
traitement en fonction des cases cochées) d'afficher la ou les
différentes URL triées (correspondant à des pages HTML présentes sur le
site) afin de permettre leur activation par le visiteur.
C'est donc d'une fonction de tri qu'il s'agit.
Si je ne me trompe et selon ce que j'ai pu apprendre (je sais, c'est pas
grand-chose ... :-( ), il faut créer une base de données et un fichier
texte pour ce faire.
Toutefois, est-il possible d'obtenir ce résultat sans créer cette base
de données et uniquement en "balayant" la série des pages html situées
dans un dossier publié chez l'hébergeur ? En effet, partant d'un certain
nombre de mots-clefs contenus dans près de 1000 pages, créer ce fichier
texte serait un boulot plutôt long ! Alors que si cette technique de
"balayage" était réalisable, ce serait évidemment plus intéressant et
moins fastidieux ...
Le formulaire ne comporte que des "checkboxes" dont les "value"
contiennent les mots-clés et le principe est de faire un tri résultant
de l'addition de toutes les options cochées.
Avec la possibilité pour le visiteur de n'en cocher qu'une partie sans
pour autant bloquer l'action du script, bien entendu.
J'espère me faire bien comprendre ...
Quelles sont les options possibles ?

[P'tit Marcel]

Post by docanski
J'envisage de créer un outil de détermination (et donc de recherche) au
départ d'un formulaire.
Ce dernier, situé à http://mycorance.free.fr/valchamp/mycdeter.html ,
devrait aboutir par l'intermédiaire d'un script PHP (faisant le
traitement en fonction des cases cochées) d'afficher la ou les
différentes URL triées (correspondant à des pages HTML présentes sur le
site) afin de permettre leur activation par le visiteur.
C'est donc d'une fonction de tri qu'il s'agit.

Apparemment, il s'agit plutôt d'une sélection que d'un tri.

Post by docanski
Toutefois, est-il possible d'obtenir ce résultat sans créer cette base
de données et uniquement en "balayant" la série des pages html situées
dans un dossier publié chez l'hébergeur ? En effet, partant d'un certain
nombre de mots-clefs contenus dans près de 1000 pages, créer ce fichier
texte serait un boulot plutôt long !

C'est difficile de répondre sans précision sur la logique qui permet de
passer des critères du formulaire vers les pages à sélectionner. Est-ce
que le nom d'une page reprend les valeurs de critère ? Ou est-ce que ces
valeurs sont dans des balises motclé html (<Meta name="keywords"...) ?


Bon champignon,

[docanski]

Alors que les eleveurs et agriculteurs polluent toujours la Bretagne,

Post by P'tit Marcel
Apparemment, il s'agit plutôt d'une sélection que d'un tri.

Si tu veux. Il s'agit, à partir d'un certain nombre d'options chosies
par le visiteur, d'utiliser la totalité des mots-clefs qui correspondent
à ces options afin de les comparer aux fiches existantes.

Post by P'tit Marcel
C'est difficile de répondre sans précision sur la logique qui permet de
passer des critères du formulaire vers les pages à sélectionner. Est-ce
que le nom d'une page reprend les valeurs de critère ? Ou est-ce que ces
valeurs sont dans des balises motclé html (<Meta name="keywords"...) ?

Les mots-clefs se trouvent dans le texte des pages HTML et non dans une
meta. La recher devrait donc consister à "balayer" chacune des fiches
afin d'y retrouver les mots-clef et, si la totalité de ceux choisis
correspondant, d'afficher l'URL (les URL) correspondantes. Si tu veux
avoir un exemple, choisis n'importe quelle fiche à partir de cette page
: http://mycorance.free.fr/valchamp/alfa.htm

Post by P'tit Marcel
Bon champignon,

;-)

Cordialement

[P'tit Marcel]

Post by docanski

Post by P'tit Marcel
Apparemment, il s'agit plutôt d'une sélection que d'un tri.

Si tu veux. Il s'agit, à partir d'un certain nombre d'options chosies
par le visiteur, d'utiliser la totalité des mots-clefs qui correspondent
à ces options afin de les comparer aux fiches existantes.

Tri : e t y u o p => e o p t u t
Sélection : e t y u o p => y o u

La sélection extrait une partie d'un ensemble
Le tri conserve l'ensemble mais l'ordonne

Post by docanski

Post by P'tit Marcel
C'est difficile de répondre sans précision sur la logique qui permet
de passer des critères du formulaire vers les pages à sélectionner.
Est-ce que le nom d'une page reprend les valeurs de critère ? Ou
est-ce que ces valeurs sont dans des balises motclé html (<Meta
name="keywords"...) ?

Les mots-clefs se trouvent dans le texte des pages HTML et non dans une
meta. La recher devrait donc consister à "balayer" chacune des fiches
afin d'y retrouver les mots-clef et, si la totalité de ceux choisis
correspondant, d'afficher l'URL (les URL) correspondantes.

Ton problème aujourd'hui est d'abord de créer des règles de
correspondance entre les mots clés choisis dans ton formulaire et le
texte des pages détail. Dans un second temps, tu choisiras s'il vaut
mieux utiliser une BDD, un fichier texte ou balayer des balises keywords
dans les pages HTML.


Pour extraire les mots clés présents dans les pages HTML, il faut faire
des analyses des pages à coup de regex un peu complexes. Voici un script
qui fonctionne :

<?php

$categories =
array('Chapeau', 'Lames', ..., 'Famille', 'Nom scientifique');

$rep = opendir('.');
if(!$rep) die('impossible de lire le répertoire');

while (($fichier = readdir($rep)) !== false) {
if(preg_match('`\.html?$`i', $fichier)) {
foreach($categories as $categorie) {
echo "<h2>$fichier: $categorie</h2>\n<PRE>";
$r = cherche_motcles($fichier, $categorie, $motscles);
if(!$r[0])
echo $r[1];
else {
print_r($motscles);
}
echo "</PRE>\n";
}
}
}
closedir($rep);

function cherche_motcles($page_html, $categorie, &$motscles) {

# pour une bonne gestion des accents
setlocale(LC_ALL, 'fr_FR');

# lire la page HTML
$page = @file_get_contents($page_html);
if(!$page) return(array(false, "page $page_html non trouvée"));

# extraire la partie descr
$masque = '`<div\sid="descr">(.*)</div>`iUs';
$ok = preg_match($masque, $page, $match);
if(!$ok) return(array(false,
"partie descr non trouvée dans $page_html:\n$page"));

# retirer les balises HTML sauf les paragraphes
$descr = strip_tags($match[1], '<p>');

# rechercher le paragraphe relatif à la catégorie
$masque = '`<p>\s*'.trim($categorie).'\s*:(.*)</p>`iUs';
$ok = preg_match($masque, $descr, $match);
if(!$ok) return(array(false,
"paragraphe $categorie non trouvé dans $page_html"));
$texte_categorie = $match[1];

# retirer les petits mots de un ou deux caractères
$masque = '`\b\w{1,2}\b`';
$texte_categorie = preg_replace($masque, '', $texte_categorie);

# éclater le texte en mots
$masque = '`[-\s.,;:/!?=+*"\'()]`';
$motscles =
preg_split($masque, $texte_categorie, -1, PREG_SPLIT_NO_EMPTY);

# suprimmer les doublons
$motscles = array_unique($motscles);

# retourner les mots-clés
return(array(true, 'ok'));

}
?>

Une fois que tu as ça, tu peux te préoccuper de l'endroit où stocker le
résultat. Le plus simple est de remplacer le print_r par une instruction
MySQL pour stocker ces mots clés dans une table. Mais ceci est une autre
histoire !

à l'avenir, quand tu crées tes pages HTML, pense à l'usage que tu veux
en faire. Ici, les mots-clés résumant chaque champignon auraient dû être
isolés du texte visible (par exemple, dans des balises META keyword) ce
qui permet ensuite de les exploiter par programme sans souci.


a+

[docanski]

Alors que les eleveurs et agriculteurs polluent toujours la Bretagne,

Post by P'tit Marcel
Tri : e t y u o p => e o p t u t
Sélection : e t y u o p => y o u

Pas bien compris, là :-(

Je dirais ainsi, en simplifiant et en limitant arbitrairement le nombre
d'options choisies :
- 5 options sont choisies dans le formulaire : abc, def, ghi, klm, nop,
par exemple
- ces options trouvent leur traduction (qui sont parfois 1, 2, 3 ou 4
mots-clefs) dans les valeurs reprises dans "value" du formulaire
- le script cherche dans le texte des 1000 fiches HTML si la *totalité*
de ces 5 options (qui peuvent donc totaliser 10 ou 20 mots-clefs) s'y
trouve
- il termine en affichant les URL des fiches comportant
*indispensablement* les mots-clefs de ces 5 options
- ainsi, toutes les fiches contenant abc, def, ghi, klm, nop pourront
être consultables par le visiteur

Post by P'tit Marcel
Ton problème aujourd'hui est d'abord de créer des règles de
correspondance entre les mots clés choisis dans ton formulaire et le
texte des pages détail.

La correspondance se traduit actuellement par la présence de mots (ou
plus rarement de préfixes "allongés") équivalents d'une part dans le
formulaire et d'autre part dans les fiches.

Post by P'tit Marcel
Dans un second temps, tu choisiras s'il vaut
mieux utiliser une BDD, un fichier texte ou balayer des balises keywords
dans les pages HTML.

Ce qui voudrait dire qu'en l'état, le traitement du formulaire serait
trop long, si je comprends bien.
Et qu'il faudrait soit remanier toutes les pages, soit créer un fichier
texte (il risque d'être très lourd, vu le nombre !) ... ou utiliser une
BDD. Ne m'étant jamais attaché à l'étude de cette notion, j'ignore même
de quoi elle peut être faite :-( mébon, il va sans doute falloir que je
m'y attèle.

Post by P'tit Marcel
Pour extraire les mots clés présents dans les pages HTML, il faut faire
des analyses des pages à coup de regex un peu complexes. Voici un script

Ta disponibilité et ta volonté d'aider me confondent !
Je vais faire quelques essais ... et avant tout tenter de comprendre un
peu le cheminement de cette sélection.

Post by P'tit Marcel
Une fois que tu as ça, tu peux te préoccuper de l'endroit où stocker le
résultat. Le plus simple est de remplacer le print_r par une instruction
MySQL pour stocker ces mots clés dans une table. Mais ceci est une autre
histoire !

Je reviendrai ! ;-)

Post by P'tit Marcel
à l'avenir, quand tu crées tes pages HTML, pense à l'usage que tu veux
en faire. Ici, les mots-clés résumant chaque champignon auraient dû être
isolés du texte visible (par exemple, dans des balises META keyword) ce
qui permet ensuite de les exploiter par programme sans souci.

Voui. Le problème est qu'un petit projet peut parfois devenir un gros
machin et qu'au départ un formulaire de recherches ou une clef de
détermination ne se justifie pas. Celui-ci a vu le jour en 1999 et il
n'était pas prévu un tel développement ! Aujourd'hui, il est devenu le
guide le plus complet du web dans cette matière ... du moins en français.

Un grand merci !
Cordialement,

[docanski]

Alors que les eleveurs et agriculteurs polluent toujours la Bretagne,

Post by P'tit Marcel
<?php
$categories =
array('Chapeau', 'Lames', ..., 'Famille', 'Nom scientifique');

... etc.

Post by P'tit Marcel
}
?>

Il y a un hic dont je n'arrive pas à trouver l'origine : lancé dans le
répertoire principal (contenant la totalité des fiches), le script
affiche la *totalité* du contenu des différentes rubriques (dont
certains titres sont visibles ci-dessus) de *toutes* les fiches présentes.
Il n'y a donc pas de tri à partir des mots-clefs choisis mais une
extraction et un affichage de la totalité du texte. :-(
Par ailleurs, il me semble inutile de faire la sélection en tenant
compte des rubriques mais d'extraire les URL correspondantes en faisant
cette sélection sur la totalité du texte, balises HTML exclues, bien
entendu.
L'affichage du contenu de ces rubriques n'est d'ailleurs pas le but
recherché mais uniquement celui des URL, sous forme de liens directement
utilisables.
Mais je demande peut-être l'impossible ... ?

Cordialement,

[P'tit Marcel]

Post by docanski
Il y a un hic dont je n'arrive pas à trouver l'origine : lancé dans le
répertoire principal (contenant la totalité des fiches), le script
affiche la *totalité* du contenu des différentes rubriques (dont
certains titres sont visibles ci-dessus) de *toutes* les fiches présentes.

c'est pas un hic, c'est ce que le programme est censé faire. à partir de
cet algorithme, tu peux construire une table de concordance entre les
mots-clés et les champignons.

En pratique, il suffit de remplacer le print_r par une insertion dans
une table de concordance, du genre :

$sql0 = "replace motcle(page, categorie, mot) values('$fichier',
'$categorie', '";
foreach($motscles as $motcle) {
$sql = $sql0 . addslashes($motcle) . "')";
mysql_query($sql) or die("erreur sql<br/>$sql<br/>".mysql_error());
}


Par la suite, tu pourras exploiter cette table dans le script appelé par
ton formulaire. Par exemple l'utilisateur précise pied cylindrique et
chapeau rond, etc.. Le script appelé récupèrera les pages correspondant
à cette description par un:

$cond = array();
$cond[] = "(categorie = 'Pied' and mot = 'cylindrique')";
$cond[] = "(categorie = 'Chapeau' and mot in ('ovoïde', 'sphérique',
'globuleux'))";
...(autres conditions)...

$sql = "select distinct page from motcle where " .
implode(" and ", $cond) . " order by page";
$res = mysql_query($sql);
if(!$res) die("erreur sql<br/>$sql<br/>".mysql_error());
if(mysql_num_rows($res)==0) {
echo "aucune page ne répond à ces critères";
}
else {
echo"Liste des pages répondant à ces critères:<br/>";
while($ligne=mysql_fetch_assoc($res)) {
echo $row['page'], "<br/>";
}
}


au préalable, tu auras créé la table vide dans la base de données avec
une commande :
create table motcle(
page varchar(50) not null default '',
categorie varchar(50) not null default '',
mot varchar(50) not null default '',
primary key(page, categorie, mot)
)
(mais là je suis carrément hors charte de ce forum sur php)

Post by docanski
Par ailleurs, il me semble inutile de faire la sélection en tenant
compte des rubriques mais d'extraire les URL correspondantes en faisant
cette sélection sur la totalité du texte, balises HTML exclues, bien
entendu.

Dans ce cas, il te suffit de virer les lignes qui exploitent la variable
$categorie. Je crois cependant que ce serait une erreur car tu mettrais
alors dans le même sac par exemple la couleur du pied et la couleur du
chapeau.


a+

[docanski]

Alors que les eleveurs et agriculteurs polluent toujours la Bretagne,

Post by P'tit Marcel
c'est pas un hic, c'est ce que le programme est censé faire. à partir de
cet algorithme, tu peux construire une table de concordance entre les
mots-clés et les champignons.

Si je comprends bien, il est nécessaire d'utiliser une base de données
créée au préalable pour faire une sélection par le résultat du
formulaire qui ira l'interroger. Ensuite, il faudra évidemment mettre le
résultat de cette sélection en musique en créant une page affichant les
URL's puisque tel est le résultat recherché. 3 étapes, en somme.
Bien compliqué pour moi dans une situation de méconnaissance totale du
langage :-(
Ton premier script ne servirait donc *que* pour créer au préalable la
base de données pour qu'elle soit stockée sur le serveur ?
Sinon, cela signifierait que chaque recherche enclenchée par la
validation du formulaire irait d'abord extraire le contenu des
catégories, les inscrirait provisoirement (je suppose ...) dans une base
de données pour ensuite en sélectionner les mots-clefs correspondant à
la demande ? Si c'est le cas, je crains que cette recherche soit trop
longue (1000 fiches, c'est beaucoup). Il serait donc préférable de créer
directement une base de données et se "contenter" d'utiliser un script
uniquement pour la sélection puis la réponse avec affichage des URL's.
J'ai bon ?
Si c'est nécessaire, je ferais bien la première partie (quoique je ne
sais même pas comment créer une table : va falloir que je potasse), puis
restera à réaliser ce script ...
Suis pas sorti de l'auberge :-(
(d'autant que je me demande si j'ai été clair dans ce qui précède ...)

Post by P'tit Marcel
En pratique, il suffit ...

Si ça pouvait être vrai (qu'il suffise) ... ;-)

Post by P'tit Marcel
au préalable, tu auras créé la table vide dans la base de données avec

...

Post by P'tit Marcel
(mais là je suis carrément hors charte de ce forum sur php)

Ah ? La création de bases de données n'est pas du même domaine ?

Post by P'tit Marcel
Dans ce cas, il te suffit de virer les lignes qui exploitent la variable
$categorie. Je crois cependant que ce serait une erreur car tu mettrais
alors dans le même sac par exemple la couleur du pied et la couleur du
chapeau.

Ok. Ça, au moins, je le retiendrai !
Merci pour ta patience et tes qualités pédagogiques. Je suis toutefois
déjà largué et je mesure le gouffre que j'ai à combler avant d'arriver à
mes fins.
Je vais commencer par tenter de comprendre le cheminement du procédé (si
c'est bien celui que j'évoque plus haut) car pour ce qui est de suivre
tes conseils dans la pratique, ça reste fort brumeux pour le moment.

Cordialement,

[P'tit Marcel]

Post by docanski
Si je comprends bien, il est nécessaire d'utiliser une base de données
créée au préalable pour faire une sélection par le résultat du
formulaire qui ira l'interroger. Ensuite, il faudra évidemment mettre le
résultat de cette sélection en musique en créant une page affichant les
URL's puisque tel est le résultat recherché. 3 étapes, en somme.
Bien compliqué pour moi dans une situation de méconnaissance totale du
langage :-(

Tu as donc une superbe opportunité pour apprendre : un besoin
irrésistible de faire partager ton goût pour les champignons, une idée
claire des étapes à suivre, des connaissances préalables de la
programmation (javascript) et un intérêt à exploiter ensuite ta nouvelle
compétence pour améliorer tes autres sites sur la Bretagne :-)

savoir utiliser HTML, CSS et javascript mais ni php ni mysql (ou leurs
équivalents), c'est comme un tennisman qui ne sait faire que des coups
droits...

a+

[Fredchou]

Post by docanski
Ce dernier, situé à http://mycorance.free.fr/valchamp/mycdeter.html ,
devrait aboutir par l'intermédiaire d'un script PHP (faisant le
traitement en fonction des cases cochées) d'afficher la ou les
différentes URL triées (correspondant à des pages HTML présentes sur le
site) afin de permettre leur activation par le visiteur.
[...]
Toutefois, est-il possible d'obtenir ce résultat sans créer cette base
de données et uniquement en "balayant" la série des pages html situées
dans un dossier publié chez l'hébergeur ? En effet, partant d'un certain
nombre de mots-clefs contenus dans près de 1000 pages, créer ce fichier
texte serait un boulot plutôt long ! Alors que si cette technique de
"balayage" était réalisable, ce serait évidemment plus intéressant et
moins fastidieux ...

Il me semble qu'il existe des outils (moteurs de recherche) qui font ça très
bien. D'autres membres de ce groupe pourront probablement t'orienter vers de
tels outils.

[Anthony]

Post by docanski
Quelles sont les options possibles ?

je pense qu'il faut voir le truc autrement.
- un script (A) qui "parse" l'ensemble des pages et balance les infos
clés dans une bd.
- le formulaire permet l'interrogation de la base sur les critères
choisis a partir d'un script (B)

mieux vaut lancer le script (A) a chaque modification / ajout de pages

plutôt que de parser l'ensemble des fichiers à chaque interrogation du
formulaire.

bien cordialement,

Anthony

[docanski]

Alors que les eleveurs et agriculteurs polluent toujours la Bretagne,

Post by Anthony
je pense qu'il faut voir le truc autrement.
- un script (A) qui "parse" ...
- le formulaire permet l'interrogation ... partir d'un script (B)

C'est ce qu'il me semble avoir conclu de mon échange avec P'tit Marcel.

Post by Anthony
mieux vaut lancer le script (A) a chaque modification / ajout de pages

Une mise à jour de la BDD, si je comprends bien.

Donc au moins 2 scripts (le premier étant celui donné par P'tit Marcel
et le second ... à créer) pour obtenir le résultat voulu ... ou un
troisième encore pour afficher les URL's correspondant à la sélection
des part.1 et part.2 ?

Post by Anthony
bien cordialement,

Tout autant,

[Bruno Desthuilliers]

Post by docanski
Bonsoir,
J'envisage de créer un outil de détermination (et donc de recherche) au
départ d'un formulaire.
Ce dernier, situé à http://mycorance.free.fr/valchamp/mycdeter.html ,

Oué ! un de mes sites préférés - surtout à l'automne !-)

Post by docanski
devrait aboutir par l'intermédiaire d'un script PHP (faisant le
traitement en fonction des cases cochées) d'afficher la ou les
différentes URL triées (correspondant à des pages HTML présentes sur le
site) afin de permettre leur activation par le visiteur.
C'est donc d'une fonction de tri qu'il s'agit.
Si je ne me trompe et selon ce que j'ai pu apprendre (je sais, c'est pas
grand-chose ... :-( ), il faut créer une base de données et un fichier
texte pour ce faire.

Ce n'est pas absolument nécessaire, mais ça peut aider oui. Enfin, la
base de données, je veux dire (je ne vois pas bien ce que le fichier
texte vient faire là-dedans.

Post by docanski
Toutefois, est-il possible d'obtenir ce résultat sans créer cette base
de données et uniquement en "balayant" la série des pages html situées
dans un dossier publié chez l'hébergeur ?

Les deux sont-ils exclusifs ?

Il serait totalement innefficace de recommencer tout le balayage à
chaque requête, d'autant que les textes à indexer ne change pas
fréquemment. La solution évidente est de créer un index (mot-clé=>liste
des pages concernées), que tu mets à jour quand tu ajoute/modifie une
page ou la liste de mots-clés.

Ceci étant, dans l'idéal, et vu la quantité de données que tu a, stocker
tout ton contenu dans une base relationnelle serait une bonne idée AMHA.

Post by docanski
En effet, partant d'un certain
nombre de mots-clefs contenus dans près de 1000 pages, créer ce fichier
texte serait un boulot plutôt long !

A la main, oui.

Post by docanski
Alors que si cette technique de
"balayage" était réalisable,

Comment fonctionne Google, à ton avis ?

Post by docanski
ce serait évidemment plus intéressant et
moins fastidieux ...
Le formulaire ne comporte que des "checkboxes" dont les "value"
contiennent les mots-clés et le principe est de faire un tri résultant
de l'addition de toutes les options cochées.
Avec la possibilité pour le visiteur de n'en cocher qu'une partie sans
pour autant bloquer l'action du script, bien entendu.
J'espère me faire bien comprendre ...
Quelles sont les options possibles ?

Déterminer le modèle de données qui convient, et écrire une moulinette
pour analyser tes fiches champignon et les injecter dans la base une
bonne fois pour toute, après quoi tu n'aurait plus besoin des pages. Il
faudra probablement fignoler quelques trucs à la main, mais pour ce que
j'ai vu de ton code source, ça doit être faisable. Accessoirement, ce
serait une bonne occasion pour "normaliser" tes fiches (ie:
formalisation des vocabulaires utilisés etc). Egalement, ça permettrait
de formaliser les différents classement possibles - par
division/sous-division/classe/sous-classe/ordre, of course, mais aussi
selon n'importe quel autre critère applicable (couleur, taille, biotope,
période de fructification, etc...).

J'avais envisagé un travail de ce genre (un genre de "mycopedia") avec
un voisin mycologue il y a une paire d'année, mais ça n'a jamais été
plus loin - faute de disponibilité de ma part principalement...

[docanski]

Alors que les eleveurs et agriculteurs polluent toujours la Bretagne,

Post by Bruno Desthuilliers
Oué ! un de mes sites préférés - surtout à l'automne !-)

Chouette, un fan ! ;-)

Post by Bruno Desthuilliers

Post by docanski
Toutefois, est-il possible d'obtenir ce résultat sans créer cette base
de données et uniquement en "balayant" la série des pages html situées
dans un dossier publié chez l'hébergeur ?

Les deux sont-ils exclusifs ?

Pas compris, là.

Post by Bruno Desthuilliers
Il serait totalement innefficace de recommencer tout le balayage à
chaque requête, d'autant que les textes à indexer ne change pas
fréquemment.

Sauf lors de mises à jour et d'ajout de fiches.

Post by Bruno Desthuilliers
La solution évidente est de créer un index (mot-clé=>liste
des pages concernées), que tu mets à jour quand tu ajoute/modifie une
page ou la liste de mots-clés.

Le script donné par P'tit Marcel répond très bien à ce besoin, me
semble-t'il ... sauf qu'il répète le nom de la page pour chaque
catégorie. Je crains que cela ne pose un petit problème pour la suite.
L'idéal serait sans doute de regrouper toutes les catégories de chaque
page en ne citant cette dernière qu'une fois. Je me trompe peut-être ...

Post by Bruno Desthuilliers
Ceci étant, dans l'idéal, et vu la quantité de données que tu a, stocker
tout ton contenu dans une base relationnelle serait une bonne idée AMHA.

Le fichier créé par le script de P'tit Marcel pèse 1,5 Mo !
C'est donc effectivement préférable pour rendre le processus de
recherche plus rapide.

Post by Bruno Desthuilliers
Déterminer le modèle de données qui convient, et écrire une moulinette
pour analyser tes fiches champignon et les injecter dans la base une
bonne fois pour toute, après quoi tu n'aurait plus besoin des pages. Il
faudra probablement fignoler quelques trucs à la main,

?

Post by Bruno Desthuilliers
Egalement, ça permettrait
de formaliser les différents classement possibles - par
division/sous-division/classe/sous-classe/ordre, of course,

Cela fait l'objet d'une rubrique voisine :
http://mycorance.free.fr/valchamp/familles.htm et de toute façon, pour
un amateur ne connaissant rien au sujet, cette partie est sans intérêt
pour la clef de détermination.

Post by Bruno Desthuilliers
J'avais envisagé un travail de ce genre (un genre de "mycopedia") avec
un voisin mycologue il y a une paire d'année, mais ça n'a jamais été
plus loin - faute de disponibilité de ma part principalement...

Toujours pas le temps ? Sinon, je suis *très* intéressé ;-)

Cordialement,

[Bruno Desthuilliers]

Post by docanski
Alors que les eleveurs et agriculteurs polluent toujours la Bretagne,

<hs>
Et c'est pas parti pour s'arrêter :(
</hs>

Post by docanski

Post by Bruno Desthuilliers
Oué ! un de mes sites préférés - surtout à l'automne !-)

Chouette, un fan ! ;-)

Non, sérieusement, ton site est une des meilleures ressources que je
connaisse sur la question (sur le net, j'entends).

Post by docanski

Post by Bruno Desthuilliers

Post by docanski
Toutefois, est-il possible d'obtenir ce résultat sans créer cette base
de données et uniquement en "balayant" la série des pages html situées
dans un dossier publié chez l'hébergeur ?

Les deux sont-ils exclusifs ?

Pas compris, là.

Un script qui fait le "balayage" à la demande, et stocke le résultat
dans la base. Ce qui évite de refaire le balayage (opération lourde) à
chaque requête.

Post by docanski

Post by Bruno Desthuilliers
Il serait totalement innefficace de recommencer tout le balayage à
chaque requête, d'autant que les textes à indexer ne change pas
fréquemment.

Sauf lors de mises à jour et d'ajout de fiches.

C'est là que tu relances le script d'indexation.

Post by docanski

Post by Bruno Desthuilliers
La solution évidente est de créer un index (mot-clé=>liste des pages
concernées), que tu mets à jour quand tu ajoute/modifie une page ou la
liste de mots-clés.

Le script donné par P'tit Marcel répond très bien à ce besoin, me
semble-t'il ... sauf qu'il répète le nom de la page pour chaque
catégorie. Je crains que cela ne pose un petit problème pour la suite.
L'idéal serait sans doute de regrouper toutes les catégories de chaque
page en ne citant cette dernière qu'une fois. Je me trompe peut-être ...

Pas assez de contexte pour savoir. Il est évident que la bonne structure
de données est celle qui convient pour le traitement à effectuer !-)

Post by docanski

Post by Bruno Desthuilliers
Ceci étant, dans l'idéal, et vu la quantité de données que tu a,
stocker tout ton contenu dans une base relationnelle serait une bonne
idée AMHA.

Le fichier créé par le script de P'tit Marcel pèse 1,5 Mo !
C'est donc effectivement préférable pour rendre le processus de
recherche plus rapide.

Accessoirement, et pour ce genre de besoins, une base emabarquée comme
SQLite est largement suffisante, et évite toute la lourdeur d'un SGBDR
comme MySQL sans renoncer à la souplesse du SQL.

Post by docanski

Post by Bruno Desthuilliers
Déterminer le modèle de données qui convient, et écrire une moulinette
pour analyser tes fiches champignon et les injecter dans la base une
bonne fois pour toute, après quoi tu n'aurait plus besoin des pages.
Il faudra probablement fignoler quelques trucs à la main,

?

Ok, je te le refais avec les notes de bas de page !-)

Post by docanski

Post by Bruno Desthuilliers
Déterminer le modèle de données qui convient,

Le schema de la base de données (tables, attributs des tables, relations
entre les tables). Travail d'analyse-conception tout ce qu'il y a de
classique.

Post by docanski

Post by Bruno Desthuilliers
et écrire une moulinette

Une "moulinette" est un script/programme ayant pour but de prendre des
données sous une forme et de les restituer sous une autre - en général,
pour migrer des données d'un système à un autre.

Post by docanski

Post by Bruno Desthuilliers
pour analyser tes fiches champignon et les injecter dans la base une
bonne fois pour toute, après quoi tu n'aurait plus besoin des pages.

L'idée est d'en finir avec les pages statiques et d'avoir un programme
spécialisé pour gérer ton site - avec une interface web permettant de
créer/modifier les 'fiches' (et le reste...).

Post by docanski

Post by Bruno Desthuilliers
Il faudra probablement fignoler quelques trucs à la main.

L'expérience prouve qu'une moulinette prenant en entrée des données
faiblement structurées (pages HTML par exemple) est généralement
incapable de gérer correctement toutes les irrégularités existantes - en
bref, la moulinette fait le gros du travail, et un humain repasse
derrière pour vérifier et éventuellement corriger.

Post by docanski

Post by Bruno Desthuilliers
Egalement, ça permettrait de formaliser les différents classement
possibles - par division/sous-division/classe/sous-classe/ordre, of
course,

http://mycorance.free.fr/valchamp/familles.htm
et de toute façon, pour
un amateur ne connaissant rien au sujet, cette partie est sans intérêt
pour la clef de détermination.

Certes, ça ne sert pas à grand chose pour le formulaire de détermination
qui est à l'origine de cette discussion. Par contre, ça évite de devoir
maintenir à la main la rubrique "familles" - dans la fiche champignon,
tu indique son classement, et quand tu affiche une fiche "famille", le
programme remonte de lui-même les références à toutes les fiches
champignon correspondantes.

Post by docanski

Post by Bruno Desthuilliers
J'avais envisagé un travail de ce genre (un genre de "mycopedia") avec
un voisin mycologue il y a une paire d'année, mais ça n'a jamais été
plus loin - faute de disponibilité de ma part principalement...

Toujours pas le temps ? Sinon, je suis *très* intéressé ;-)

Le temps de faire tout ça *tout seul*, clairement, non. En tous cas pas
avant d'ici une bonne paire d'années...

Par contre, si tu a des compétences en dev PHP - ou si tu es partant
pour en acquérir -, on peut discuter d'une éventuelle collaboration.

[docanski]

Alors que les eleveurs et agriculteurs polluent toujours la Bretagne,

Post by Bruno Desthuilliers
Un script qui fait le "balayage" à la demande, et stocke le résultat
dans la base. Ce qui évite de refaire le balayage (opération lourde) à
chaque requête.

Donc il se fait après chaque mise à jour ou ajout de fiches par
l'administrateur afin de stocker les résultats de manière à les rendre
plus rapidement accessibles dès la première requête.

Post by Bruno Desthuilliers
Pas assez de contexte pour savoir. Il est évident que la bonne structure
de données est celle qui convient pour le traitement à effectuer !-)

Le contexte est simple : extraction des mots-clefs situés dans 6
rubriques de chaque fiche/url et stockage de ceux-ci dans la base. Le
script de P'tit Marcel est parfait pour cette extraction mais possède un
défaut (que j'ai tenté de comprendre et modifier "en aveugle" sans
résultat) : la répétitivité du nom de page pour chaque rubrique au lieu
du groupage des 6 rubriques sous une seule inscription du nom de page.

Post by Bruno Desthuilliers
Accessoirement, et pour ce genre de besoins, une base emabarquée comme
SQLite est largement suffisante, et évite toute la lourdeur d'un SGBDR
comme MySQL sans renoncer à la souplesse du SQL.

Je vais m'informer à ce sujet.

Post by Bruno Desthuilliers
Une "moulinette" est un script/programme ayant pour but de prendre des
données sous une forme et de les restituer sous une autre

Ce qui correspond au script de P'tit Marcel, si je suis bien.

Post by Bruno Desthuilliers
L'idée est d'en finir avec les pages statiques et d'avoir un programme
spécialisé pour gérer ton site - avec une interface web permettant de
créer/modifier les 'fiches' (et le reste...).

C'est bien joli tout ça ... mais ça suppose que je retouche la totalité
des pages du site ! :-(

Post by Bruno Desthuilliers

Post by Bruno Desthuilliers
Il faudra probablement fignoler quelques trucs à la main.

L'expérience prouve qu'une moulinette ... est généralement
incapable de gérer correctement toutes les irrégularités ... et un humain repasse
derrière pour vérifier et éventuellement corriger.

Pfiou ! Eliminer les irrégularités, passe encore, mais attribuer un
nouvel index pour garder une indexation logique (je parle ici des [1]
[2] etc ...) si certaines chaines de caractères sont éliminées, ça
risque d'être très long.

Post by Bruno Desthuilliers
Certes, ça ne sert pas à grand chose pour le formulaire de détermination

Ce n'est donc pas un sujet de préoccupation pour le moment.

Post by Bruno Desthuilliers
Par contre, ça évite de devoir
maintenir à la main la rubrique "familles" ...

Dans le cadre d'une refonte complète XHTML -> PHP, alors.

Post by Bruno Desthuilliers
Par contre, si tu a des compétences en dev PHP - ou si tu es partant
pour en acquérir -, on peut discuter d'une éventuelle collaboration.

Aucune compétence : PHP est une inconnue et je dois tout apprendre.
J'ai téléchargé une série de tutoriels, retrouvé 2 bouquins traînant
dans ma bibliothèque (encore sous cello d'origine) "Pages Web
dynamiques" et "PHP 4 developpement" de Campus Press pour m'attaquer au
sujet.
Ça risque de prendre du temps : mon DD physique est presque saturé :-).

Cordialement,

[Bruno Desthuilliers]

Post by docanski
Alors que les eleveurs et agriculteurs polluent toujours la Bretagne,

Post by Bruno Desthuilliers
Un script qui fait le "balayage" à la demande, et stocke le résultat
dans la base. Ce qui évite de refaire le balayage (opération lourde) à
chaque requête.

Donc il se fait après chaque mise à jour ou ajout de fiches par
l'administrateur afin de stocker les résultats de manière à les rendre
plus rapidement accessibles dès la première requête.

Post by Bruno Desthuilliers
Pas assez de contexte pour savoir. Il est évident que la bonne
structure de données est celle qui convient pour le traitement à
effectuer !-)

Le contexte est simple : extraction des mots-clefs situés dans 6
rubriques de chaque fiche/url et stockage de ceux-ci dans la base. Le
script de P'tit Marcel est parfait pour cette extraction mais possède un
défaut (que j'ai tenté de comprendre et modifier "en aveugle" sans
résultat) : la répétitivité du nom de page pour chaque rubrique au lieu
du groupage des 6 rubriques sous une seule inscription du nom de page.

Je n'ai pas regardé ce script de près, mais je pense que c'est
relativement trivial à corriger le cas échéant.

Post by docanski

Post by Bruno Desthuilliers
Accessoirement, et pour ce genre de besoins, une base emabarquée comme
SQLite est largement suffisante, et évite toute la lourdeur d'un SGBDR
comme MySQL sans renoncer à la souplesse du SQL.

Je vais m'informer à ce sujet.

Post by Bruno Desthuilliers
Une "moulinette" est un script/programme ayant pour but de prendre des
données sous une forme et de les restituer sous une autre

Ce qui correspond au script de P'tit Marcel, si je suis bien.

Bouge pas, je regarde... (...)

Oui et non. Disont qu'en général, une moulinette ne sert qu'une fois...
Et ce à quoi je pense, c'est non pas juste construire un index, mais
réinjecter *tout* le contenu actuel du site - ou du moins cette partie
(les fiches champignons etc) - dans une base, et de générer les pages
dynamiquement à partir de la base. De la gestion de contenu, quoi.

Post by docanski

Post by Bruno Desthuilliers
L'idée est d'en finir avec les pages statiques et d'avoir un programme
spécialisé pour gérer ton site - avec une interface web permettant de
créer/modifier les 'fiches' (et le reste...).

C'est bien joli tout ça ... mais ça suppose que je retouche la totalité
des pages du site ! :-(

Ca suppose d'écrire une moulinette pour tout injecter dans la base - il
n'est bien sûr pas question de faire ça à la mano. Bref, de passer d'un
site essentiellement statique à un site dynamique. Crois moi, c'est
beaucoup moins de maintenance...

Post by docanski

Post by Bruno Desthuilliers

Post by Bruno Desthuilliers
Il faudra probablement fignoler quelques trucs à la main.

L'expérience prouve qu'une moulinette ... est généralement incapable
de gérer correctement toutes les irrégularités ... et un humain
repasse derrière pour vérifier et éventuellement corriger.

Pfiou ! Eliminer les irrégularités, passe encore, mais attribuer un
nouvel index pour garder une indexation logique (je parle ici des [1]
[2] etc ...) si certaines chaines de caractères sont éliminées, ça
risque d'être très long.

Excuse moi, mais je ne comprends pas de quoi tu parles. Tu peux
préciser, s'il te plait ?

Post by docanski

Post by Bruno Desthuilliers
Certes, ça ne sert pas à grand chose pour le formulaire de détermination

Ce n'est donc pas un sujet de préoccupation pour le moment.

Post by Bruno Desthuilliers
Par contre, ça évite de devoir maintenir à la main la rubrique
"familles" ...

Dans le cadre d'une refonte complète XHTML -> PHP, alors.

D'une refonte statique -> dynamique. Rien n'empêche les pages générées
d'être du xhtml valide (bien au contraire), et rien n'implique a priori
que le langage de programmation soit PHP. Mais bon, PHP a au moins
l'avantage d'être à peu près adapté à ce genre de tâches - ou du moins
d'être couramment employé pour !-)

Post by docanski

Post by Bruno Desthuilliers
Par contre, si tu a des compétences en dev PHP - ou si tu es partant
pour en acquérir -, on peut discuter d'une éventuelle collaboration.

Aucune compétence : PHP est une inconnue et je dois tout apprendre.

Des compétences en programmation dans d'autres langages ?

Post by docanski
J'ai téléchargé une série de tutoriels, retrouvé 2 bouquins traînant
dans ma bibliothèque (encore sous cello d'origine) "Pages Web
dynamiques" et "PHP 4 developpement" de Campus Press pour m'attaquer au
sujet.

<hs>
Je ne suis pas sûr de garder un très bon souvenir de ce que j'ai vu chez
campus-press en général.
</hs>

Post by docanski
Ça risque de prendre du temps : mon DD physique est presque saturé :-).

Moi c'est la RAM et le proc biologiques qui sature ces derniers temps :-/

Post by docanski
Cordialement,

De même.

[docanski]

Alors que les eleveurs et agriculteurs polluent toujours la Bretagne,

Post by Bruno Desthuilliers

Post by docanski
Ce qui correspond au script de P'tit Marcel, si je suis bien.

Bouge pas, je regarde... (...)
Oui et non. Disont qu'en général, une moulinette ne sert qu'une fois...
Et ce à quoi je pense, c'est non pas juste construire un index, mais
réinjecter *tout* le contenu actuel du site - ou du moins cette partie
(les fiches champignons etc) - dans une base, et de générer les pages
dynamiquement à partir de la base. De la gestion de contenu, quoi.

Ta réflexion porte donc sur une refonte totale du concept de base
aujourd'hui "limité" à un XHTML statique.

Post by Bruno Desthuilliers

Post by docanski
Pfiou ! Eliminer les irrégularités, passe encore, mais attribuer un
nouvel index pour garder une indexation logique (je parle ici des [1]
[2] etc ...) si certaines chaines de caractères sont éliminées, ça
risque d'être très long.

Excuse moi, mais je ne comprends pas de quoi tu parles. Tu peux
préciser, s'il te plait ?

L'extraction des mots effectuées dans les rubriques des pages crée une
indexation de ceux-ci de la manière suivante :
___________________
champiX.htm. chapeau
[0] => conique
[1] => maturité
[2] => brun
[3] etc ...
___________________
Si je fais un nettoyage à la main des mots non repris dans la liste des
mots-clefs du formulaire, j'élimine donc le "[1] => maturité". Ce
faisant, l'indexation (si je puis utiliser ce terme ...=) passe de [0] à
[2] et si je ne corrige pas ce "trou", je suppose que cela posera
problème pour le script destiné à faire la sélection.
Ai-je tort ?

Post by Bruno Desthuilliers
Des compétences en programmation dans d'autres langages ?

Qui datent ! DOS et basic à l'origine (mais ou le if -> elseif -> else
-> était plutôt du if -> then -> else parfois associé à du goto ou
gosub, etc) mais devenu obsolète (et d'ailleurs presqu'entièrement
oublié) suivi d'un apprentissage très limité à JS il y a une dizaine
d'années pour quelques besoins ponctuels.
Une "logique" peut-être parfois un peu semblable à PHP mais avec des
termes différents ... et surtout beaucoup plus limitée. Le problème
réside donc essentiellement dans mes capacités de mémorisation de termes
nouveaux ... et d'une "logique" sans doute aussi un peu différente.
Le handicap essentiel : le DD physique ; à partir d'un certain âge, ses
cylindres finissent par rouiller ... :-(
Si tu connais un tutoriel pour les nuls (en français !) *telechargeable*
(car je ne dispose que du RTC) sur le net, n'hésite pas à m'en donner
l'url !

Cordialement,

[Bruno Desthuilliers]

Post by docanski
Alors que les eleveurs et agriculteurs polluent toujours la Bretagne,

(snip)

Post by docanski
Ta réflexion porte donc sur une refonte totale du concept de base
aujourd'hui "limité" à un XHTML statique.

Exactly.

Post by docanski

Post by Bruno Desthuilliers

Post by docanski
Pfiou ! Eliminer les irrégularités, passe encore, mais attribuer un
nouvel index pour garder une indexation logique (je parle ici des [1]
[2] etc ...) si certaines chaines de caractères sont éliminées, ça
risque d'être très long.

Excuse moi, mais je ne comprends pas de quoi tu parles. Tu peux
préciser, s'il te plait ?

L'extraction des mots effectuées dans les rubriques des pages crée une
___________________
champiX.htm. chapeau
[0] => conique
[1] => maturité
[2] => brun
[3] etc ...

Ok...

Post by docanski
Si je fais un nettoyage à la main des mots non repris dans la liste des
mots-clefs du formulaire, j'élimine donc le "[1] => maturité". Ce
faisant, l'indexation (si je puis utiliser ce terme ...=) passe de [0] à
[2] et si je ne corrige pas ce "trou", je suppose que cela posera
problème pour le script destiné à faire la sélection.
Ai-je tort ?

Oui. L'idée dans ce cas est de définir - lors de la mise au point de la
moulinette - un "vocabulaire" standardisé, qui sera celui utlisé pour
l'indexation finale. Ensuite, on défini pour la moulinette un
dictionnaire de correspondances pour les synonymes recensés (ie :
brunâtre=>brun, etc...) dans les données existantes, de sorte qu'on
puisse, à partir du synonyme, affecter le terme correspondant du
vocabulaire standard. Accessoirement, on procède d'une façon similaire
pour les liens entre pages etc...

Ensuite, lors de la création de nouvelles fiches, on se sert du
vocabulaire standard (lequel est bien sûr extensible). On peut également
envisager de conserver le dictionnaire des synonymes en base en
prévision de recherches libres sur ces attributs.

En ce qui concerne "le script de sélection", ça devient essentiellement
un script qui construit une requête SQL. Ce qui, là aussi, n'est pas
vraiment du niveau des sciences aérospatiales en matière de complexité.

Post by docanski

Post by Bruno Desthuilliers
Des compétences en programmation dans d'autres langages ?

Qui datent ! DOS et basic à l'origine (mais ou le if -> elseif -> else
-> était plutôt du if -> then -> else parfois associé à du goto ou
gosub, etc) mais devenu obsolète (et d'ailleurs presqu'entièrement
oublié) suivi d'un apprentissage très limité à JS il y a une dizaine
d'années pour quelques besoins ponctuels.
Une "logique" peut-être parfois un peu semblable à PHP mais avec des
termes différents ... et surtout beaucoup plus limitée. Le problème
réside donc essentiellement dans mes capacités de mémorisation de termes
nouveaux ... et d'une "logique" sans doute aussi un peu différente.
Le handicap essentiel : le DD physique ; à partir d'un certain âge, ses
cylindres finissent par rouiller ... :-(

Bah... M'en parlez pas, mon bon monsieur...

Post by docanski
Si tu connais un tutoriel pour les nuls (en français !) *telechargeable*
(car je ne dispose que du RTC) sur le net, n'hésite pas à m'en donner
l'url !

Hmmm... Il y a pas mal de tutoriel pour les nuls, mais ils sont
généralement aussi "par des nuls".

PHP n'est pas en soi spécialement complexe, mais hélas très irrégulier à
tous les niveaux, ce qui le rends impossible à bien mémoriser (ça fait
plusieurs années maintenant que j'utilise ce langage très régulièrement,
et je suis toujours obliger d'avoir la doc sous la main). Ceci étant,
les deux vrais difficultés sont de comprendre le protocole HTTP (ce qui
est indispensable dès qu'on fait du développement web), le SQL et un peu
de théorie sur les bases relationnelles, et de définir une architecture
propre pour éviter de mélanger allègrement logique applicative et
présentation.

Pour le reste, si tu sais ce que sont une variable, une fonction, un
branchement et une boucle, ya pas grand chose de plus sorcier que ça en PHP.