Ce que je propose, c'est carément de nouveaux filtres dédiés à l'affichage
de contrôles de formulaires.
Ils seront nécessaires, mais je ne suis pas sûr qu'il en existe de suffisamment
généraux à cette problématique pour être intégrés à la distribution officielle.
Et aussi de nouveaux pseudo critères dans les boucles pour dire si c'est un
INSERT, UPDATE ou DELETE
Là ça me parait hors sujet: les boucles actuelles sont fondées exclusivement sur un SELECT,
parce que c'est une instruction SQL qui renvoie une sortie exigeant une mise en page soignée,
alors que ces 3 instructions ne posent pas ce problème.
En poussant la réflexion, je me suis rendu compte qu'il faudrait sans doute
un boucle supplémentaire pour gérer un affichage avant et après remplissage
du formulaire :
<BOUCLE_TraitementFormulaire(POSTBACK)></BOUCLE_TraitementFormulaire>
// traitements à faire pour afficher le formulaire
</B_TraitementFormulaire>
// traitements à faire si le formulaire a été renvoyé et est valide
<//B_TraitementFormulaire>
Ou précises-tu la table dont il s'agit ?
Le traitement d'un formulaire n'a rien d'itératif, ça relève donc d'un filtre, pas d'une boucle.
Je précise les idées exprimées tout à l'heure.
On se donnerait un nouveau champ #TABLE, et il faudrait écrire un filtre
presentation_de_formulaire faisant (en mieux) ce que le script tablextra.php fait en methode GET,
à savoir une production de <input> et/ou <textarea> avec comme action l'appel d'un script faisant
un Insert (en gros ce que fait tablextra.php appelé en POST).
Ca donnerait alors:
<BOUCLE_insere(matable)></BOUCLE_insere>#TABLE|presentation_de_formulaire<//B_insere>
Pour l'update, on aurait un nouveau champ #LIGNE et il faudrait un filtre presqu'identique
au précédent, mais pré-remplissant les input et textarea avec le contenu présent de l'entrée.
Ca donnerait:
<BOUCLE_maj(ARTICLES){id_article}>#LIGNE|formulaire_prerempli</BOUCLE_maj>
Le deuxième aspect est celui de squelettes créant des scripts
utilisables dans l'espace privé,
autrement dit de réécrire celui-ci avec des squelettes.
Effectivement, c'est tentant d'un côté, mais ça pose pour moi un problème
*majeur* : celui de l'homogénéité des sites sous SPIP : aujourd'hui, quand
on sait écrire dans un site SPIP, on sait quasiment écrire dans tous
Voila qui me surprend: l'espace public d'un site sous Spip change du tout au tout
si on n'utilise pas les squelettes standards, pourquoi refuser cette souplesse à l'espace privé ?
Il y aurait des squelettes standards que les administrateurs du site seraient libres
d'utiliser ou pas. Vu le nombre de demandes de modifs de l'espace privé qui arrivent sur cette liste,
je soupçonne que beaucoup d'espaces privés ne sont déjà plus standards suite à des bidouilles peu
portables (j'en ai fait moi-même). Il s'agit de donner un cadre à ces bidouilles, qui s'en plaindrait ?
esj