[spip-dev] Formulaires dans fonctions...

Dev
1

Salut,

Pas mal de modifs dans les fichiers:

/inc-public.php3
/spip_style.css
/inc-calcul-squel.php3
/inc-calcul.php3

et un nouveau:

/inc-formulaires.php3

Il s'agit du traitement des formulaires, d=E9sormais regroup=E9s dans des
fonctions (dans inc-public.php3, j'ai laiss=E9 une partie de l'ancien
code en remarque...), dans le fichier /inc-formulaires.php3.

Sauf erreur, seuls les formulaires INSCRIPTION et SIGNATURES
n=E9cessitaient de tels modifications (les autres sont d=E9j=E0 dans des
fonctions).

Particularit=E9: l'affichage du formulaire et le traitement ont lieu
sur la m=EAme page. De cette fa=E7on, quand on effectue une "r=E9ponse" =E0
un formulaire, celui-ci est remplac=E9 par les messages de traitement.
Pour les r=E9ponses du formulaire, nouvelle classe CSS:
=2Ereponse_formulaire
(par d=E9faut, en gras rouge...)

Autant que possible, j'ai essay=E9 =E9galement de nettoyer un poil le
code (bof bof), effectivement c'=E9tait particuli=E8rement crado (surtout
le traitement des signatures des p=E9titions). J'ai fait ce que j'ai
pu, avec des $GLOBALS (bon, j'ai red=E9fini des variables locales =E0
partir de ces GLOBALS, histoire de pas m'enquiquiner avec tout le
code), et des include_local. Mais je suis conscient que c'est tr=E8s
tr=E8s perfectible...

Ca doit m=E9riter d'=EAtre particuli=E8rement test=E9, parce que sur ce genr=
e
de choses, je suis pas du tout s=FBr de moi...

=3D=3D=3D=3D

Ah oui, les URLS (REQUEST_URI) sont trait=E9es =E0 la main (oui, je sais,
eurk...). Je suppose que c'est le type d'endroit o=F9 il serait
pratique d'utiliser la nouvelle classe pour les liens, mais j'ai pas
os=E9 attaquer avec =E7a.

ARNO*

2

@ Arno* (arno@scarabee.com) :

Pas mal de modifs dans les fichiers:

/inc-public.php3

...

Il s'agit du traitement des formulaires, désormais regroupés dans des
fonctions (dans inc-public.php3, j'ai laissé une partie de l'ancien
code en remarque...), dans le fichier /inc-formulaires.php3.

En effet, le fichier inc-public.php3 va passer de 16ko à 4ko, ce qui devrait
accélérer le rendu des pages en cache. Excellent !

Je corrige dans inc-calcul un petit bug que j'avais introduit (quand on
utilisait un squelette-dist.html sans id_rubrique), et je passe la fonction
page_parent($fond, $id_rubrique) d'inc-public vers inc-calcul (là où elle
doit être vu que c'est là qu'elle sert), et je restructure la chose comme
suit :

function chercher_squelette($fond, $id_rubrique) {
    // cherche le squelette $fond=$id_rubrique.html
    // sinon va chercher recursivement dans la hierarchie
    // en appelant la fonction ci-dessous cherche_squelette_hierarchie
    ...
}

function cherche_squelette_hierarchie($fond, $id_rubrique) {
    // recherche recusrive d'un squelette $fond-$id_rubrique.html
    // sinon $fond.html
    // sinon $fond-dist.html
    // sinon rien (ne se produit que s'il y a un bug dans le fichier
    // .php3 appelant : à ce moment-là on pourrait peut-être installer
    // un message d'erreur destiné au webmaster ?)
    ...

}

-- Fil

3

    // sinon rien (ne se produit que s'il y a un bug dans le fichier
    // .php3 appelant : à ce moment-là on pourrait peut-être installer
    // un message d'erreur destiné au webmaster ?)

C'est fait dans inc-calcul.php3 : si le webmaster se plante et met ceci dans
article.php3 :

<?
    $fond="articles"; // notez le 's' final
    ...
?>

Au lieu de faire plein de warnings et d'erreur '.html not found', spip se
fend d'un joli message

    Erreur sur le site

    Aucun squelette "articles" n'est disponible...

-- Fil

4

Salut

Modifs dans l'espace public, j'ai ajouté l'utilisation de include_local()
là où ça manquait. J'ai également corrigé ce qui semblait être un bug :
le fichier fond=$id_rubrique était cherché récursivement, ce qui est
contraire à la définition donnée par Arno. J'ai enfin corrigé deux-trois
bizarreries dans la gestion des pétition.

a+

Antoine.