Un éclair de lucidité, tout d'un coup...
Bien sûr que c'est un problème de cache !
De toutes façons c'était clair au début de votre message : "l'internaute
doit recalculer la page...".
Mais ça je l'ai lu trop vite, et je me suis attaché à ce que je
remarquais dans la suite.
Donc, si je reprends le code, on a bien dans la foulée l'une de l'autre
l'exécution de la mise à jour puis la boucle "amap_saison", non ?
Alors c'est normal : quand on est passé par #CACHE{0} au début de la
page, ça voulait simplement dire de ne pas aller chercher les infos dans
le cache mais de les lire dans la base de données.
Or si je ne me trompe, l'interprétation des boucles précède l'exécution
de ce qui est PHP, donc au sein de cette page, Spip a successivement :
. lu la base de données pour avoir les données "amap_saison"
. puis exécuté le reste, dont la mise à jour... trop tard !
Si mon hypothèse est la bonne, ce qu'il faut c'est que l'affichage soit
réalisé dans un nouvel appel de page Spip.
Par exemple, en terminant la page "sorties_ferme.html" par un simple
affichage du genre "Vos modifications ont été enregistrées", avec un
bouton ou un lien "Continuer".
L'attribut "href" du lien (ou l'attribut "action" de la <form> contenant
le bouton devra être de la forme indiquée précédemment : #URL_ARTICLE...
Et là, à mon avis, le tour est joué...
(enfin, j'espère que ça n'est pas une illusion)
Fred
----- Original Message -----
*From:* sonic steph <mailto:ml@dadaprod.org>
*To:* spip@rezo.net <mailto:spip@rezo.net>
*Cc:* Frédéric Barboteu <mailto:cfreed@orange.fr>
*Sent:* Thursday, November 13, 2008 4:11 PM
*Subject:* Re: [Spip] créer son propre formulaire sous Spip
Merci Frédéric de cette réponse très détaillée qui m'a permit d'avancer
sur mon formulaire..
Par contre, j'ai encore un soucis avec le cache, l'internaute doit
recalculer la page s'il veut que l'ajout dans la table donné soit
affiché des extraits de la table que j'affiche systématiquement..
pour résumé, dans le fichier article.html, j'ai l'appel suivant :
<BOUCLE_mot_amap3 (MOTS) {id_article}{titre_mot=sorties_ferme}>
<INCLURE{fond=../amap/includes/sorties_ferme}{id_article}>
</BOUCLE_mot_amap3>
puis dans le fichier sorties_ferme.html, j'ai ceci:
#CACHE{0}
<?php
include(_DIR_PLUGIN_AMAP."/inc/fonctions_participation_contrat.php");
if ( isset($_POST['idSortie']) && isset($_POST['idContrat']) )
{
echo "<hr/><div class='verdana2' style='text-align:
justify'>".table_amap_post_participation_contrat()."</div><hr/>";
}
?>
<BOUCLE_amap_saison(amap_saison){id_article_sorties=#ENV{id_article}}>
...
La partie boucle du fichier sorties_ferme.html permet d'afficher l'état
de mes tables, cette partie n'est pas affiché à jour après le post
d'ajout dans les tables...
merci
stéphane
Frédéric Barboteu a écrit :
> Bonjour,
>
> C'est le genre de problème que je me suis posé récemment.
>
> Etant familier des développements PHP mais pas de Spip, j'ai cherché
> une stratégie qui permette simultanément :
>
> * de rende les deux parties aussi indépendantes l'une de
l'autre que
> possible, pour laisser toute liberté de programmation dans la
> partie PHP
> * de présenter cependant les pages issues de PHP dans un contexte
> (en-tête, pied, etc...) qui reste strictement contrôlé par Spip
> * et bien sûr de permettre un retour sans problème à la mécanique
> Spip ordinaire
>
> Ma solution, qui jusqu'à preuve du contraire remplit bien ces
objectifs,
> est construite comme suit
>
> * un article particulier correspond à "l'entrée" dans la zone
PHP :
> il ne comporte qu'un titre (puisqu'obligatoire pour Spip), à
> l'exclusion de tout contenu (mais on pourrait imaginer aussi en
> mettre un, qui serait récupéré et utilisé au sein de la zone
PHP)
> * un squelette spécial est réservé à cet article particulier,
repéré :
> o soit par son id_article, solution qui établit la
> correspondance "en dur" au niveau du squelette
> o soit par un mot-clé : dans ce cas, la correspondance reste
> dynamiquement modifiable à travers l'espace privé
> * la méthode pour dispatcher entre squelettes "normal" et
> "spécial" est la suivante (exemple ici basé sur l'hypothèse d'un
> squelette initial "article.html" unique, et d'un repérage du
> squelette spécial par le mot-clé "php") :
> o le contenu du squelette "article.html" est modifié
> pour devenir :
> + parties communes à la présentation de la page
> (en-tête, parties gauche et droite...)
> + boucle d'aiguillage (voir ci-après), qui remplace le
> "contenu central ordinaire" (boucle articles...)
> + parties communes à la présentation de la page (pied)
> o le "contenu central ordinaire" éliminé de
"article.html" est
> placé dans un sous-squelette "inc-article.html"
> o un sous-squelette "inc-article-php.html" est créé pour
> recevoir la page PHP
> o la boucle d'aiguillage ressemble à ceci :
> <B_php>
> <BOUCLE_ords(MOTS) {id_article} {titre=php}>
> [(#REM) squelette spécial PHP]
> <INCLURE{fond=inc-article-php} {id_article}
{env=#ENV}>
> </BOUCLE_php>
> </B_php>
> <INCLURE{fond=inc-article} {id_article} {env=#ENV}
{lang}>
> <//B_php>
> o w
> * la programmation à l'intérieur du sous-squelette spécial
> ("inc-article-php.html" dans cet exemple) se conforme
> aux principes suivants :
> o commencer par une balise
> #CACHE{0}
> indispensable pour éviter les pénibles demandes de
recalcul
> par Spip, qui retournent la page avec un $_POST vide et
> obligent à recommencer le test depuis le début : avec
cette
> balise, un simple {F5} suffit après modification du
source PHP
> o par rapport à une programmation PHP classique, remplacer
> tous les
> include(module.php);
> par des
> ?><INCLURE{fond=module} {id_article}><?php
> (la mention de id_article est fondamentale)
> o toute balise HTML <form> doit comporter les attributs
> suivants :
> + method="post" : les données saisies dans le
formulaire
> transitent par "post"
> + action="#URL_ARTICLE..." : l'information id_article
> transite automatiquement par "get" ; les points de
> suspension correspondent à des infos complémentaires
> qu'on peut décider de transmettre pour les
besoins de
> la logique PHP, sous forme classique "¶m=valeur"
> o tous les liens "internes" à la zone PHP (c'est-à-dire
> passant d'une page PHP à une autre sans retour au contexte
> global de Spip) doivent être de la forme
> <a href="#URL_ARTICLE...">
> (même remarque que ci-dessus pour les paramètres
> complémentaires)
> o la mécanique d'ensemble est donc basée sur le fait que
tout
> changement de page au sein de la zone PHP rappelle le même
> article Spip, et donc le même sous-squelette
> "inc-article-php.html".
> C'est à celui-ci d'assurer un aiguillage interne entre ses
> différentes branches, selon le déroulement du dialogue, en
> gérant les infos complémentaires envoyées par les <form
> action...> ou les <a href...>.
> Une solution-type consiste à définir par exemple un
> paramètre "cible", valorisé selon les besoins dans les
> différentes portions de la zone PHP, et à débuter le
> sous-squelette par quelque chose comme :
> switch ($cible = @$_GET['cible']) {
> case 'faire_ceci':
> ?><INCLURE{fonds=faire_ceci} {id_article}><?php
> break;
> case 'faire_cela':
> ?><INCLURE{fonds=faire_cela} {id_article}><?php
> break;
> ...
> default:
> echo '<br />Paramètre "cible" invalide :
> "'.$cible.'" !';
> }
>
> Voilà mon "état de l'art" personnel en la matière, et comme disent les
> anglo-saxons : HTH...
>
> Fred
>
>
> ----- Original Message -----
> *From:* sonic steph
> *To:* spip@rezo.net <mailto:spip@rezo.net>
> *Sent:* Wednesday, November 12, 2008 8:08 PM
> *Subject:* [Spip] créer son propre formulaire sous Spip
>
>
> Je n'ai pas encore trouvé de page web qui creuse un peu cet
aspect..
>
> en regardant les formulaires qui tournent déjà sur le site, par
> exemple :
>
> <form method='post' action='spip.php?rubrique12#form1'
> enctype='multipart/form-data'>
>
> je ne vois que la résultante HTML classique avec a priori dans
> l'attribut action de la balise champ l'appel de la rubrique dans
> laquelle se trouve le formulaire.. comment se passe le traitement
> ensuite ? Le post renvoie à une séquence particulière dans spip je
> suppose, où est-elle définie ?
>
> Pour être plus précis, ce que je cherche à faire : créer un
formulaire
> basique qui va permettre d'ajouter des lignes dans une table
externe à
> spip... a priori, je pourrai appeler un script php comme sur
n'importe
> quel site web, faire l'ajout dans la base, mais reste à voir
ensuite
> comment afficher une page de retour, c'est à dire appeler un
squelette..
> je pourrai faire une redirection avec la fonction header vers un
> squelette statique.. mais je pense qu'il doit y avoir une
manière de
> faire cela plus spip ?
>
> merci de vos lumières sur ce sujet...
>
> stéphane
>
> --
> Nouveau single de Michel Sardon : OGM Pas !
>
_____________________________________________________________________
> réseaux d'artistes autoproduits, label autogéré, plateforme de
> téléchargement libre, média indépendant
> -----------------------
> http://www.dadaprod.org
>
_____________________________________________________________________
>
> _______________________________________________
> liste spip
> spip@rezo.net <mailto:spip@rezo.net> - désabonnement :
spip-off@rezo.net <mailto:spip-off@rezo.net>
>
> Infos et archives : http://listes.rezo.net/mailman/listinfo/spip
>
> Documentation de SPIP : http://www.spip.net/
>
> irc://irc.freenode.net/spip ou
>
http://embed.mibbit.com/?server=irc.freenode.net&channel=%23spip
<http://embed.mibbit.com/?server=irc.freenode.net&channel=%23spip>
--
Nouveau single de Michel Sardon : OGM Pas !
_____________________________________________________________________
réseaux d'artistes autoproduits, label autogéré, plateforme de
téléchargement libre, média indépendant
-----------------------
http://www.dadaprod.org
_____________________________________________________________________