- lors de l'enregistrement d'un objet on reconnait les raccourcis qui inserent un formulaire et on maintient les liens
- sur la fiche d'un formulaire on affiche les objets qui l'utilise
- sur la fiche d'un objet on affiche les formulaires utilisés
- correction du modèle <formXX> pour ne pas mettre en cache le formulaire dans le site public tout en affichant le formulaire dans l'espace privé
- introduction du modèle <formidableXX> qui permet d'inserer un formulaire avec une syntaxe courte pour #ID_FORMULAIRE=XX
- chaines de langue et styles
- recreation des liens formulaires-articles lors de l'import f&t

Pour le moment, on ne rattrape pas les liens sur les formulaires déjà utilisés dans des contenus sur une installation existante de formidable. Pour forcer la mise à jour des liens il suffit d'enregistrer le contenu qui utilise un formulaire

- les formulaires a la poubelles
- les reponses associees a un formulaire supprimé
- les reponses a la poubelle
- les champs des reponses associés à une réponse supprimée

formulaire_formidable_#ID_FORMULAIRE
formulaire_formidable_#IDENTIFIANT

A l'installation les formulaires importés de f&t ont tous l'identifiant formXX avec XX l'ancien ID de form dans f&t
Du coup le modele <formXX> recupere le formulaire avec identifiant formXX et assure la compatibilte des contenus existants

Les actions supprimer ne font que mettre en statut poubelle/refuse, plus de risque de pertes de données à cause d'une action maladroite
on enleve le bouton "Supprimer" sur la page d'un formulaire

Lors de l'import f&t les formulaires sans réponses sont mis en statut proposé, les autres en publiés

on ajoute une recherche sur la page des reponses, ça ne marche qu'avec le patch http://core.spip.org/projects/spip/repository/revisions/21176

bugfix sur breadcrumb des reponses et formulaires non publies
formulaire de recherche dans la page des formulaires
nombre de formulaires et de reponses dans les listes

a l'installation de formidable, import automatique de tous les formulaires et sondages de forms&tables
(mais il manque la prise en compte du statut, qui serait mieux, et surtout l'import des données, prochain step)

il manquait la gestion des type 'textestatique' qui s'importe en simple explication, et l'import des champs monnaie et num était éronné (taille correspond au nombre de décimales)

refactoring est completion de l'import depuis xml forms&tables (il manque encore les fieldset et les file)

chaines de langue pour les statuts, liste des réponses plus claire, et filtrage des réponses par statut dans la page des réponses (onglets Toutes/A modérer/Validées/Supprimées)

listes formulaires et reponses : homogeneiser avec les conventions de SPIP 3 (titre, ordre des colonnes)
On supprime l'action dupliquer/supprimer sur la liste des formulaires, il faut aller sur un form pour faire l'operation
mais on ajoute le nombre de réponses et un lien vers la page des réponses

on masque le gros message vert et le gros bouton "Reinitialiser" trop affordants qui sont proposés par saisies.
 A la place un message simple en haut, et le bouton "Revenir à la dernière version enregistrée" dans le cartouche en bas, qui apparaissent dès qu'une saisie est modifiée

afficher toutes les infos du formulaire sur la page de vue, l'aide memoire de la colonne extra ne s'affichait pas dans tous les cas, traitement propre sur le message de retour

quand le formulaire n'a encore aucun champ de saisie, soyons un peu plus smart et convivial dans ce qu'on affiche : un message qui explique la situation plutot qu'un bouton "enregistrer" sorti de nulle part et incompréhensible

squelette HTML du formulaire d'edition, declaration champs_editables et champs_versionnes dans l'API tables_objets_sql, nommage génériques et implémentation des fonctions de editer/formulaire (avec support des vieux nommages)
+ ajout d'une chaine de langue sur erreur de format
+ bugfix verification unicité de l'identifiant

Attention : on branche le trunk en v1 qui reste la version stable. Le trunk va subir du nettoyage/refactoiring et passe en v2-dev

Correction rapide des valeurs par défaut, lors du chargement, on insère les options "defaut" en tant que valeurs du charger() comme le fait d'ailleurs Saisies dans son API. Le mieux serait évidemment d'utiliser les "nouveautés" (plus tant que ça) de Saisies dans Formidable.

Cela devrait corriger toutes ces saisies "selection" ou "oui_non" qui n'affichaient pas les bonnes valeurs par défaut.

Les dernière modifs sur "date_crea" avait pété Formidable chez tous ceux qui l'avaient déjà et ne l'installaient pas à zéro.

En effet, au moins en MySQL, il *faut* indiquer le type de donnée quand on fait un CHANGE sur le nom d'un champ, on ne peut pas juste donner le nouveau nom.

Du coup ça ne jouait pas la requête et on avait toujours "date_crea" dans la base.

Ajout d'une date de création du formulaire (nommée date_crea parce que date est un mot reservé mysql)
Incrémentation mineure de version et de shéma