DocumentationFormsTables

Différence entre un formulaire et une table

-  un formulaire est dédié a la saisie de données dans l’espace public (collecte d’informations) ; les réponses sont stockées pour pouvoir les suivre/gérer/traiter, comme des forums... Ce qui est central ici c’est la collecte d’informations dans l’espace public, et le stockage est seulement destiné à du post-traitement

-  une table est une structure de données destinées à être utilisées dans les squelettes. Ce qui est central ici, c’est les données et leur manipulation pour les afficher dans les pages de l’espace public. La
saisie est juste un moyen de créer/modifier des données, mais pas unique (l’import/export csv en est un autre)

Le socle commun permet de disposer du formulaire de saisie associé, utilisable aussi bien dans l’espace privé que dans l’espace public si besoin. La définition de la structure de la table se fait par la définition de son masque de saisie, c’est-à-dire son formulaire de saisie.

(extrait d’un mail de Cedric sur spip-zone le 07/12/2006)

Pour définir une table, on définit ses champs à travers le
formulaire de saisie.
Chaque champ peut être :
-  spécifiant : il sera considéré comme pertinent pour
trier/filtrer/rechercher les données dans la table
-  public : les données de ce champ sont affichées dans les modeles ,
dans le cas contraire elle ne sont visibles que dans l’espace privé
-  obligatoire : le champ doit être rempli lors de la saisie

Par ailleurs, une aide contextuelle peut être définie pour chaque champ.
Le wrapping html permet de définir des encapsulations des champs dans la
vue donnée (typiquement pour faire du microformat), sur le format :
-  implicite : la donnée est inserée au milieu de l’encapsulation qui
peut comporter plusieurs tags

<div class='truc'></div>

-  explicite : la donnée est inserée a la place du $1

<a href='$1' class='truc'>$1</a>

Le plugin contient un exemple de structure hCard
(snippets/forms/hCard.xml) qui utilise ce format.
Mais la fonctionnalité encore incomplète, il manque la possibilité de
gérer une hiérarchie de div englobants. (Les fieldsets sont utilisés
pour gérer un premier niveau de groupe, mais il est nécessaire de
pouvoir faire des sous groupes, j’y refléchis).

Le hCard.xml contenu dans le plugin est importable à l’aide du plugin
snippets (1.9.2 uniquement) qui permet de gerer des imports/exports des
structure des tables&formulaires en xml. Un formulaire peut etre exporté
et réimporté dans un formulaire existant, auquel cas les champs y seront
ajoutés.

Les types de champ sont personnalisables, il y a un exemple dans
etc/forms_types_champs.xml. Cela permet de définir des formats qui n’ont pas de vocation a être en dur car ne correspondent pas a un besoin général. Pour le moment la vérification de format est limitée a un
preg_match sur une regexp, mais je pense a mettre un pipeline pour
permettre de créer des types de champs plus complexes.

Le plugin csv_import fonctionne avec les tables de forms&tables, et il
permet de faire de l’import/export csv des données (en ajout et mise a
jour si l’id_donnee est fourni).

Les tables définies dans forms&tables sont en fait toutes stockées dans
les mêmes tables physiques. Dans les squelettes, on utilise les boucles
FORMS_DONNEES et FORMS_CHAMPS sur le mode :

<BOUCLE_reponses(FORMS_DONNEES){id_donnee}>
<BOUCLE_champs(FORMS_CHAMPS){id_form}{par rang}>
#TITRE : #LESVALEURS{','}
</BOUCLE_champs>
</BOUCLE_reponses>

la balise #LESVALEURS permet d’éviter une boucle supplémentaire sur
FORMS_DONNEES_CHAMPS. Dans cette dernière boucle, #VALEUR retourne non
le champ sql brut mais la valeur en clair dans le cas ou il s’agit d’un
champ mot clé, select ou multiple. #VALEUR* retourne elle le champ sql brut.

sur la boucle FORMS_DONNEES,
-  le critère tout permet de récupérer les données non validées
-  le critère statut=.. de récupérer les données non publiées (par
défaut seules les données avec le statut publie sont retournées par la
boucle)
-  le critère id_mot=.. de récupérer toutes les données associées à un
mot clé. Cela suppose que la table comporte au moins un champ de type
mot clé

sur la boucle FORMS_CHAMPS
-  par défaut seuls sont retournés les champs public
-  le critère tout permet de récupérer tous les champs

Voila un petit aperçu des fonctionnalités, cela mériterait évidemment
une grosse doc que je n’ai pas du tout le temps de faire en ce moment.
(notamment sur l’utilisation avancée du plugin comme support pour
d’autres plugins : créations de tables sur structure xml, création d’un
type de table supplémentaire pour gérer des tables qui ne soient pas
mélangées avec celles du module tables par défaut, utilisation de l’API
d’interface liste/édition/modification ... des tables ....)

Cedric

Utilisation :

Insertion d’un formulaire dans une article :
Le formulaire créé s’insère dans un champ texte d’article ou de rubrique avec un modèle <formxx>
Voir spip contrib

Insertion des données de table dans un article
Un modèle simple <tablexx> permet d’afficher les données d’un table dans un article.

Premier article de présentation générale initié sur Spip-contrib
puisqu’il faut bien commencer par quelque chose .. c’est la http://www.spip-contrib.net/ecrire/...

vous ètes convié à y participer, soit via le forum de rédac, soit en vous proposant comme (co)rédacteur