Mettons que je crée un nouvel objet éditorial 'toto' pour un plugin lambda.
D'autres plugins permettent d'être activés sur certains objets éditoriaux, qui sont choisis sur sa page de configuration.
Par exemple pour le plugin 'Media', dans Configuration -> Contenu du site -> Documents joints, le nouvel objet éditorial 'toto' apparaît dans la liste des objets éditoriaux.
Comment faire pour éviter ça ? Dans mon cas, il faudrait que l'objet toto soit 'invisible' aux autres objets.
Mettons que je crée un nouvel objet éditorial 'toto' pour un plugin lambda.
D'autres plugins permettent d'être activés sur certains objets
éditoriaux, qui sont choisis sur sa page de configuration.
Par exemple pour le plugin 'Media', dans Configuration -> Contenu du
site -> Documents joints, le nouvel objet éditorial 'toto' apparaît dans
la liste des objets éditoriaux.
Comment faire pour éviter ça ? Dans mon cas, il faudrait que l'objet
toto soit 'invisible' aux autres objets.
Bonjour
Faire un var_mode=inclure sur la page de l'espace privé en question,
identifier l'inclure à modifier,
surcharger le fichier, par exemple via un plugin conteneur perso crée vite fait et vraiment bien fait par La Fabrique (plugin)
ceci dit pour spip3
Mettons que je crée un nouvel objet éditorial 'toto' pour un plugin lambda.
D'autres plugins permettent d'être activés sur certains objets
éditoriaux, qui sont choisis sur sa page de configuration.
Par exemple pour le plugin 'Media', dans Configuration -> Contenu du
site -> Documents joints, le nouvel objet éditorial 'toto' apparaît dans
la liste des objets éditoriaux.
Comment faire pour éviter ça ? Dans mon cas, il faudrait que l'objet
toto soit 'invisible' aux autres objets.
Peux-tu expliciter un peu plus ton cas d'utilisation ?
Parce que si c'est pour un objet générique, même si toi pour l'instant t'as pas envie de pouvoir lier des choses dessus, d'autres personnes le voudront peut-être.
Si en fait ce n'est pas un objet éditorial, alors tu peux le déclarer par le pipeline "declarer_tables_principales" comme avant, plutôt que "declarer_tables_objets_sql" et du coup la table sera déclarée mais ça ne sera pas reconnu comme un objet manipulable.
@rburton : Surcharger le formulaire de sélection, je n'y avais pas pensé. Il s'agit du formulaire 'inc-choisir-objets.html'.
Cependant il me faudrait une solution plus générique, que se passe-t-il si 2 plugins activés décident de surcharger le même formulaire ?
J'ai besoin du même comportement pour plusieurs plugins à la fois.
@rastapopoulos : En ce qui concerne mon cas d'utilisation : j'ai par exemple fais un petit fork du plugin 'coordonnées'. Ce plugin rajoute 4 objets (adresse, mail, téléphone, site internet) que l'on peut lier aux autres objets.
En revanche ça n'a pas de sens de pouvoir lier d'autres objets (point géolocalisé, document, chat, etc.) à ces 4 objets.
D'où le besoin de ne pas faire figurer ces 4 objets sur les formulaires de sélection des autres plugins.
Donc la solution de la pipeline 'declarer_tables_principales' me semble appropriée, par contre avant d'essayer, je me demande si c'est une solution pérenne ?
Je précise que ce sont des plugins pour Spip 3, est-ce que cette pipeline sera amenée à être dépréciée maintenant que 'declarer_objets_sql' la remplace ?
Le 10/07/2012 16:01, RastaPopoulos a écrit :
Peux-tu expliciter un peu plus ton cas d'utilisation ?
Parce que si c'est pour un objet générique, même si toi pour l'instant
t'as pas envie de pouvoir lier des choses dessus, d'autres personnes le
voudront peut-être.
Si en fait ce n'est pas un objet éditorial, alors tu peux le déclarer
par le pipeline "declarer_tables_principales" comme avant, plutôt que
"declarer_tables_objets_sql" et du coup la table sera déclarée mais ça
ne sera pas reconnu comme un objet manipulable.
@rastapopoulos : En ce qui concerne mon cas d'utilisation : j'ai par
exemple fais un petit fork du plugin 'coordonnées'. Ce plugin rajoute 4
objets (adresse, mail, téléphone, site internet) que l'on peut lier aux
autres objets.
En revanche ça n'a pas de sens de pouvoir lier d'autres objets (point
géolocalisé, document, chat, etc.) à ces 4 objets.
D'où le besoin de ne pas faire figurer ces 4 objets sur les formulaires
de sélection des autres plugins.
Bof.
Je rejoins Rasta : ces formulaires sont là uniquement pour les webmestres et définissent les propriétés du site. Franchement c'est pas dramatique si ces objets sont vus par ceux qui configurent le site.
Le cas typique est Champs Extras 3 : ah bon ? tu penses que quelqu'un n'aura pas un champ à ajouter par rapport à ceux que tu as créé toi ? que personne ne voudra mettre de photo du lieu sur une adresse ? huhu, c'est mal connaître les gens : la preuve, tu as forké Coordonnées plutôt que de l'adapter également
