Faire un tri a partir d'un formulaire

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+
--
P'tit Marcel

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 !-)

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.

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.

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.

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

Comment fonctionne Google, à ton avis ?

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...

Alors que les eleveurs et agriculteurs polluent toujours la Bretagne,
Bruno Desthuilliers nous narre ce qui suit en ce 11/05/2007 9:29 :

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

Chouette, un fan ! ;-)

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à.

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.

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 ...

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.

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,

?

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.

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,
--
docanski

- Les Côtes du nord de la Bretagne par le sentier des douaniers
- Memento des champignons : le guide le plus complet du Web
- Et d'autres sujets encore sur ----> http://armorance.free.fr

Alors que les eleveurs et agriculteurs polluent toujours la Bretagne,

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

Bruno Desthuilliers nous narre ce qui suit en ce 11/05/2007 9:29 :

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).

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.

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.

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 !-)

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.

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 !-)

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.

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.

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...).

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.

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.

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.

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.

Alors que les eleveurs et agriculteurs polluent toujours la Bretagne,
Bruno Desthuilliers nous narre ce qui suit en ce 13/05/2007 18:16 :

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.

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.

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.

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.

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 ! :-(

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.

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.

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

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

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,
--
docanski

- Les Côtes du nord de la Bretagne par le sentier des douaniers
- Memento des champignons : le guide le plus complet du Web
- Et d'autres sujets encore sur ----> http://armorance.free.fr

Alors que les eleveurs et agriculteurs polluent toujours la Bretagne,
Bruno Desthuilliers nous narre ce qui suit en ce 13/05/2007 18:16 :

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.

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.

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.

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.

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...

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 ?

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.

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 !-)

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 ?

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>

Ç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 :-/

Cordialement,
De même.

Alors que les eleveurs et agriculteurs polluent toujours la Bretagne,
Bruno Desthuilliers nous narre ce qui suit en ce 14/05/2007 7:37 :

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.

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 ?

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,
--
docanski

- Les Côtes du nord de la Bretagne par le sentier des douaniers
- Memento des champignons : le guide le plus complet du Web
- Et d'autres sujets encore sur ----> http://armorance.free.fr

Alors que les eleveurs et agriculteurs polluent toujours la Bretagne,
Bruno Desthuilliers nous narre ce qui suit en ce 14/05/2007 7:37 :

(snip)

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

Exactly.

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 ...

Ok...

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é.

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...

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.