+// Pour utiliser les champs "supplementaires", il faut installer dans le
fichier
+// ecrire/mes_options.php3 une fonction definissant les champs en
question,
+// pour chaque type d'objet (article, rubrique, breve, auteur ou mot) que
l'on
+// veut ainsi etendre
+
+/* Arguments :
+ * $type = "article", "rubrique", "auteur" ...
+ * $id_objet = id de l'article, de la rubrique ...
+ * $ensemble = id de la rubrique de l'article, le parent de la rubrique,
+ * le statut de l'auteur, type du mot...
+ * Retour : un tableau au format (champ => description, champ => desc
...)
+ * ou la description est au format "type|filtre[|pretty name]"
+ * type = ligne, bloc, texte
+ * filtre = brut, typo, propre (a appliquer dans l'espace prive)
+ * prettyname (optionnel) = nom du champ tel qu'on l'affiche dans l'esp.
prive
+ */
Le réglage des champs devrait être stocké dans la base et disposer
d'une interface de paramétrage, pas faire appel à un bout de code compliqué
dans mes_options.php3 (qui n'est là que pour les options qu'on ne peut
_pas_ mettre ailleurs)...
Oui, mais la structure même de l'extension n'est pas mûre (je pense par
exemple que le $ensemble ne convient pas, pour les articles et les rubriques
ils faudrait passer l'id_secteur plutpot que l'id_parent, ça serait plus
pertinent)
Tout ça pour dire qu' on ne va pas faire une interface si tôt que ça ; hum !
on n'a toujours pas d'interface pour ajouter des types de documents
Sinon #SUPPLEMENT est cryptique, #EXTENSION serait dix fois plus clair
(on peut sûrement éviter le conflit avec les types de documents, voire
remplacer le #EXTENSION actuel par #EXTENSION_FICHIER... je ne pense
pas que beaucoup de monde l'utilise).
Je pense que si, mais avec un bon gros warning lors de la mise à jour...
c'est vrai qu'EXTENSION est vraiment mieux que SUPPLEMENT.
Hi hi. Cela dit, je ne vois pas très bien comment on pourrait paramétrer les
extensions sans mettre du code ; c'est un peu comme inc-urls, ce truc :
chacun peut en faire ce qu'il veut... s'il faut les mettre dans
mes_extensions.php3 plutôt que danes mes_options.php3, pourquoi pas. Mais
sinon j'ai du mal à voir...
Bon, dans un ancien squelette par défaut, il y avait
<BOUCLE_portfolio(DOCUMENTS){id_article}{extension==jpg|png|gif}{mode=document}{doublons}{0,3}>
donc difficile maintenant de changer le sens de {extension}...
si on veut autre chose de SUPPLEMENT, il faudrait trouver vite. une idée ?
Sinon, à la réflexion, urlencode() est peut-être mieux que serialize(), car
les regexp sont plus faciles à former pour aller chercher "l'article donc
l'extra 'isbn' contient un 'u'"... Votre avis ?
Sinon, à la réflexion, urlencode() est peut-être mieux que serialize(), car
les regexp sont plus faciles à former pour aller chercher "l'article donc
l'extra 'isbn' contient un 'u'"... Votre avis ?
Personne n'a d'opinion ? rawurlencode() a comme défaut d'étendre énormément
tout ce qui est binaire (en utf8 ça va faire mal). Mais il est plus facile à
analyser en regexp... je n'arrive pas à trouver d'argument décisif entre les
deux. L'idéal serait de n'encoder que les séparateurs de champs, mais il
faut tout de même un encodage standard (une fonction php) et pas un truc
fait "à la main"...
