|
|
|
|
@ -9,11 +9,6 @@
|
|
|
|
|
- utiliser une config en session comme le constructeur de formulaire de saisies ?
|
|
|
|
|
- pb à résoudre : pouvoir faire une prévisualisation des blocs en cours d'édition sur la page de l'objet
|
|
|
|
|
|
|
|
|
|
[ ] Pouvoir brancher un type de block sur un modèle auto-documenté (html + yaml)
|
|
|
|
|
- dans ce cas, on ne gère plus les paramètres des blocks avec le constructeur de formulaire
|
|
|
|
|
- on utilise un yaml pour chaque blocktype et on supprime la colonne saisies des blockstypes
|
|
|
|
|
- au moment de l'édition d'un block, remonter les saisies du modèle / du blocktype dynamiquement
|
|
|
|
|
|
|
|
|
|
## blocktypes
|
|
|
|
|
|
|
|
|
|
**Technique**
|
|
|
|
|
@ -24,6 +19,9 @@
|
|
|
|
|
[ ] Si le type de block est associable aux rubriques, pouvoir restreindre son utilisation à une branche
|
|
|
|
|
- remarque idem point précédent
|
|
|
|
|
|
|
|
|
|
[ ] Pouvoir brancher un type de block sur un modèle auto-documenté (html + yaml), ou un blocks/*.yaml spécifique
|
|
|
|
|
- continuer à utiliser en parallèle le constructeur de formulaire ? il est quand même très pratique
|
|
|
|
|
|
|
|
|
|
[ ] Gestion de champs de type fichiers : comment les associer aux blocks ?
|
|
|
|
|
- comme des documents liés dont l'id est référencé dans la valeur du champ, en plus d'un lien dans spip_documents_liens ? (hum...)
|
|
|
|
|
- avec des rôles dynamiques ? (hum...)
|
|
|
|
|
|
