[spip-dev] Nouveau compilateur et écriture dans la base

Bonsoir,

Si j'ai bien suivi, le nouveau compilateur permet d'utiliser ses propres
tables dans les boucles dans le but d'*afficher* le contenu de ces tables
via #NOM_DU_CHAMP. C'est une avancée formidable qui m'amène à en imaginer
une autre.

Est-ce qu'il serait envisageable de disposer d'une syntaxe dans les boucles
permettant d'*écrire* dans la base ?
Et tant que j'y suis, qui générerait les champs de formulaire dans les
squelettes ?

Idées de syntaxe en vrac :
- [(#NOM_CHAMP|input_text{10,"expressionreg de validation"})]
- [(#NOM_CHAMP|input_textarea{40,10,"expressionreg de validation"})]
- [(#NOM_CHAMP|input_select{"option1","option2","option3"})]

- <BOUCLE_maboucle(MATABLE){pour insertion}>
- <BOUCLE_maboucle(MATABLE){pour miseàjour}>
- <BOUCLE_maboucle(MATABLE){pour effacement}>

Ce n'est qu'un brouillon pour l'instant, mais y'a peut-être là une piste à
creuser...

Cordialement,
Jacques - www.pyrat.net

Il y a deux aspects différents.

Le premier a commencé à être discuté dans le forum de
http://www.spip-contrib.net/ecrire/articles.php3?id_article=573
avec Courcy et s'est poursuivie off-line: il s'agit de pouvoir
crééer des formulaires de remplissage d'une table à partir de sa description en PHP.
La conclusion à laquelle nous sommes arrivés est qu'on devrait introduire un nouveau
champ #TABLE qui retournerait le tableau PHP en question et sur lequel on
appliquerait un filtre qui pourrait en faire ce qu'il veut,
en particulier retourner un formulaire de remplissage total ou partiel,
avec un graphisme ad hoc.
On a aussi songé à une variante qui, employée à l'interieur des balises BOUCLE et /BOUCLE,
retournerait ce tableau avec non plus les types SQL mais les valeurs des champs
pour ce passage dans la boucle (i.e. fournirait tout simplement le résultat du fetch_array
avec un SELECT * comme requête).

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. Je suis favorable à cette idée qui me parait
dans la logique de ce qu'est Spip, mais c'est un gros chantier, et il vaudrait mieux d'abord éprouver
le premier aspect.

Je rappelle que dans la contrib cité en référence, il y a un petit script "tablextra.php"
qui est un embryon de ce genre de choses.

esj

Déesse A. wrote:

Est-ce qu'il serait envisageable de disposer d'une syntaxe dans les
boucles
permettant d'*écrire* dans la base ?
Et tant que j'y suis, qui générerait les champs de formulaire dans
les squelettes ?

Idées de syntaxe en vrac :
- [(#NOM_CHAMP|input_text{10,"expressionreg de validation"})]
- [(#NOM_CHAMP|input_textarea{40,10,"expressionreg de validation"})]
- [(#NOM_CHAMP|input_select{"option1","option2","option3"})]

- <BOUCLE_maboucle(MATABLE){pour insertion}>
- <BOUCLE_maboucle(MATABLE){pour miseàjour}>
- <BOUCLE_maboucle(MATABLE){pour effacement}>

Il y a deux aspects différents.

Le premier a commencé à être discuté dans le forum de
http://www.spip-contrib.net/ecrire/articles.php3?id_article=573
avec Courcy et s'est poursuivie off-line: il s'agit de pouvoir
crééer des formulaires de remplissage d'une table à partir de sa
description en PHP.
La conclusion à laquelle nous sommes arrivés est qu'on devrait
introduire un nouveau
champ #TABLE qui retournerait le tableau PHP en question et sur lequel
on
appliquerait un filtre qui pourrait en faire ce qu'il veut,
en particulier retourner un formulaire de remplissage total ou
partiel, avec un graphisme ad hoc.
On a aussi songé à une variante qui, employée à l'interieur des
balises BOUCLE et /BOUCLE,
retournerait ce tableau avec non plus les types SQL mais les valeurs
des champs
pour ce passage dans la boucle (i.e. fournirait tout simplement le
résultat du fetch_array
avec un SELECT * comme requête).

Je suis allé lire le forum en question.
Ce que je propose, c'est carément de nouveaux filtres dédiés à l'affichage
de contrôles de formulaires.
Et aussi de nouveaux pseudo critères dans les boucles pour dire si c'est un
INSERT, UPDATE ou DELETE

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>

Le modèle de traitement des formulaires de .NET de M$ pourrait fournir une
source d'inspiration...

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
(/exception faite des sites faisant un usage massif des mots clefs pour
changer leur comportement/)

Je rappelle que dans la contrib cité en référence, il y a un petit
script "tablextra.php"
qui est un embryon de ce genre de choses.

Il faudrait que je regarde ça.
Il me semble aussi avoir vu passer sur www.phpclasses.org un générateur de
formulaires automatiques avec contrôle (/vérification de la conformité et du
respect de certaines règles, éventuellement par regexp/) des éléments
renvoyé.

En tout cas, je vois bien que se lancer là dedans est un autre travail de
longue halène :wink:

Jacques - www.pyrat.net

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

Déesse A. wrote:

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 ?

Personnelement, je ne m'en plaindrait pas.
Ce que j'exprimais était le souvenir que j'avais d'une telle discussion sur
ce groupe de news.
Il me semble qu'Arno* ou Antoine ou Fil ont dit qu'il n'était pas
souhaitable de pouvoir facilement modifier l'interface privée de manière
importante parce que ça ferait perdre en universalité.
autrement dit, une force de SPIP, c'est qu'une personne formée au
back-office de SPIP est de facto capable d'intervenir dans plusieurs sites
sous SPIP.
Bémol : la v1.8 aura une interface sérieusement différente des 1.6 et 1.7,
donc, on aura des différences entre un admin formé sur 1.7 et un sous 1.8...

Jacques - www.pyrat.net

Déesse A. wrote:

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.

Certes.
Ceux que j'ai sugérés allaient dans le sens de la généralité.

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.

Un exemple sera peut-être plus clair:
<BOUCLE_maboucle(MATABLE){pour effacement}{id_matable=$id_matable}>
</BOUCLE_maboucle>
Est une boucle qui générerait le SQL suivant :
DELETE * FROM MATABLE where id_matable=(la valeur de $id_matable);

Donc, cela permettrait d'avoir une généralisation du principe des boucles,
pas seulement des select, mais aussi, Insert, Update, Delete et ça, sans
avoir à apprendre le SQL

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 ?

Dans une boucle intérieure du type de celle donnée en exemple ci dessus.
En fait, cette pseudo boucle est une simulation de :
si formulaire renvoyée et valide
    traitement pour écriture dans la base
sinon
    affichage du formulaire (éventuellement avec les indications de ce qui
n'est pas valide)
fin si
C'est en tout cas comme ça que je fais mes pages de formulaire à la main.

Le traitement d'un formulaire n'a rien d'itératif, ça relève donc d'un
filtre, pas d'une boucle.

Mais c'est conditionnel et la syntaxe des boucle traite le conditionnel

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>

Avoir une génération automatique du formulaire entier me gène
Je serais plus pour une génération contrôle par contrôle.
Pour les select ou option, il faudrait même pouvoir spécifier au choix si
les options sont prises dans un liste (fournie) ou dans une table de
référence.

Jacques - www.pyrat.net

cela permettrait d'avoir une généralisation du principe des boucles,
pas seulement des select, mais aussi, Insert, Update, Delete et ça, sans
avoir à apprendre le SQL

J'ai bien compris, mais est-ce le but de Spip ?

Avoir une génération automatique du formulaire entier me gène

Qui peut le plus peut le moins:
je propose des champs décrivant toute la table, c'est aux filtres de ... filtrer ce qu'ils veulent.

esj

Bien que l'idee elle-meme ne me deplait pas, je voudrais signaler que la
modification de la base a partir de squelettes presente un enorme probleme au
niveau de la securite...
Imagine ta boucle et quelqu'un qui apelle
http://host/article.php3?id_matable="IN (SELECT id_matable from MATABLE)"...

Bien sur, cet exemple ne marchera pas, mais tu vois le probleme: en
implementant cela il faudrait securiser a mort le compilateur des squelettes
et introduire des milliers de tests supplementaires pour empecher ce genre
d'injection SQL...

A voir si ca vaut le coup.
./Maciek

Maciek Borowka wrote:

Déesse A. wrote:

cela permettrait d'avoir une généralisation du principe des boucles,
pas seulement des select, mais aussi, Insert, Update, Delete et ça,
sans
avoir à apprendre le SQL

J'ai bien compris, mais est-ce le but de Spip ?

Initialement, non.
Mais on peut vouloir par exemple faire un sondage dans SPIP.
Aujourd'hui, y'a des contrib, des scripts extérieurs.
En pouvant écrire dans la base depuis un squelette sans php, on pourrait
faire des sondages rien qu'avec des boucles spip (et exit le module de
sondage de SPIP-AGORA)

Ou alors, faire remplir un formulaire de demande d'infos

Ou pour SPIP phpBB, avoir des champs supplémentaires pour le profil de
l'auteur

Ou avec un catalogue de produit, un caddie virtuel...

Bref, avoir un CMS puissance 10 !

Avoir une génération automatique du formulaire entier me gène

Qui peut le plus peut le moins:
je propose des champs décrivant toute la table, c'est aux filtres de
... filtrer ce qu'ils veulent.

Le problème, c'est que pour changer l'apparence d'un formulaire, il faudrait
savoir toucher au php, ce qui est loin d'être le cas de tous les spipeurs.
Avec une précision au niveau du contrôle, cela permet de réalise *sa* mise
en page.

Les 2 pourraient coexister :
- formulaire entier
- niveau contrôle

Jacques - www.pyrat.net

cela permettrait d'avoir une généralisation du principe des boucles,
pas seulement des select, mais aussi, Insert, Update, Delete et ça,
sans
avoir à apprendre le SQL

J'ai bien compris, mais est-ce le but de Spip ?

Sans doute pas, mais un tel systeme permettrait d'utiliser les boucles pour
l'espace privé (puisqu'il faudrait de toutes facons securiser un peu la
chose, ce qui ne necessite pas de faire des classes de 3500 lignes ni des
milliers de tests ...).
Ca fait un bon moment que je pense à la chose, personnellement je suis pour,
mais on revient dans la discussion "faut il rendre le back office
customisable ...".
Les arguments du non tiennent la route, mais il faut etre réaliste : si un
client le demande, on le fait de toutes facons ... je prefererai le faire
proprement, et mutualiser les couches d'accès aux données entre le back
office et le site public (au dela de la spip_query) me semble une bonne
chose pour l'evolutivité et la maintenabilité, non ?

Avoir une génération automatique du formulaire entier me gène

Qui peut le plus peut le moins:
je propose des champs décrivant toute la table, c'est aux filtres de
... filtrer ce qu'ils veulent.

Personnellement, j'aime beaucoup l'approche utilisée pour les champs extras.
Ne pourrait on pas envisager de decrire, independament de la structure que
tu proposes, qui contient forcement toute la table, chaque champs avec une
approche "formulaire" (type, longueur, liste de choix ...) ?
On peut imaginer placer tous les champs non decrits sous form de input
hidden.
Faire un generateur de formulaire c'est bien, le faire parametrable, c'est
mieux.
Maintenant, ou et comment le coder ... pas sur qu'on puisse s'en sortir
juste avec des filtres, mais ca reste à voir.

@++

Dans tablextra.php, je déduis du type SQL la balise adaptée
(textarea pour un blob, input pour un varchar, hidden+value=now pour un datetime ...).
C'est assez frustre, mais effectivement on peut penser à tableau isomorphe
où la valeur associée à un champ serait sa balise de saisie adpatée,
ou le nom d'une fonction PHP dont l'appel fournirait cette balise
(si on veut un HTML dépendant du contexte).

esj