[spip-dev] extension des capacites de inc_extra

Dev
1

Bonjour!

J'ai soudainement eu besoin d'avoir plus de contrôle sur l'apparition
des champs "extras" dans les articles. J'ai écrit une patch permettant
de restreindre l'application des champs non seulement sur le
"id_secteur" mais aussi et surtout sur la rubrique parent ou le numéro
de l'élément touché (article, auteur, etc).

La patch est disponible, avec documentation et une brève justification
sur:

http://spipquebec.org/article.php3?id_article=30

La patch s'applique "clean" sur 1.7 beta, alors je crois que vous
n'aurez pas de problème à la tester.

J'espère que ceci saura attirer votre intérêt et considération.
J'attends vos commentaires avec impatience.

A.

2

J'ai soudainement eu besoin d'avoir plus de contrôle sur l'apparition
des champs "extras" dans les articles. J'ai écrit une patch permettant
de restreindre l'application des champs non seulement sur le
"id_secteur" mais aussi et surtout sur la rubrique parent ou le numéro
de l'élément touché (article, auteur, etc).

Déjà l'#extra est si compliqué qu'on a décidé de ne pas le documenter pour
l'instant et de le garder en alpha ; mais là on complique encore, et si je
vois bien que c'est utile dans certains cas, on sort quand même du cadre de
SPIP, qui tient à avoir des objets relativement propres et une doc
lisible... je pense qu'il faut encore réfléchir sur cette question, plutôt
que de coder comme des fous dans le cadre assez étroit qui a été proposé.

Mais tes propositions sont intéressantes dans le sens où elles montrent 1)
l'intérêt d'une possibilité d'extension des objets ; 2) des tentatives, avec
ce que ça permet et ce qui coince. Donc : continue !! :wink:

Peut-être que la proposition récente de faire une table d'extras serait plus
propre ? Il faudrait essayer d'y réfléchir... (et proposer une méthode
migration si on franchit le pas).

-- Fil

3

Salut!

Fil wrote:

J'ai soudainement eu besoin d'avoir plus de contrôle sur l'apparition
des champs "extras" dans les articles. J'ai écrit une patch permettant
de restreindre l'application des champs non seulement sur le
"id_secteur" mais aussi et surtout sur la rubrique parent ou le numéro
de l'élément touché (article, auteur, etc).

Déjà l'#extra est si compliqué qu'on a décidé de ne pas le documenter pour
l'instant et de le garder en alpha ; mais là on complique encore, et si je
vois bien que c'est utile dans certains cas, on sort quand même du

cadre de

SPIP, qui tient à avoir des objets relativement propres et une doc
lisible... je pense qu'il faut encore réfléchir sur cette question, plutôt
que de coder comme des fous dans le cadre assez étroit qui a été proposé.

Malheureusement ou heureusement, je produis des sites avec ça moi! Et vu
que SPIP est GPL, je dois aussi publier mes modifications, ce qui n'est
pas sans me faire plaisir. :slight_smile:

Sans farce, je suis d'accord, il est évident que inc_extra est encore en
mode ultra-alpha, et je considère mon code comme de l'expérimentation,
sans plus, mais qui peut déjà être utile.

Mais tes propositions sont intéressantes dans le sens où elles montrent 1)
l'intérêt d'une possibilité d'extension des objets ; 2) des

tentatives, avec

ce que ça permet et ce qui coince. Donc : continue !! :wink:

Merci.

Peut-être que la proposition récente de faire une table d'extras

serait plus

propre ? Il faudrait essayer d'y réfléchir... (et proposer une méthode
migration si on franchit le pas).

L'avantage des modifications que je suggère est que c'est "backward
compatible" à fond: aucune modifications nécessaires aux mes_options.

Je vois deux choses séparées dans ces modifications:

1- la méthode de stockage des définitions et des relations inc_extra

2- l'interface pour accéder aux dites relations

Que (1) soit dans un array() PHP (comme présentement) ou dans une table,
ce n'est qu'un changement de "backend", tant qu'à moi, où la table offre
plus de puissance. Mais on a pas encore de code pour la table, alors je
fais sans. :slight_smile:

C'est pour (2) que je voulais m'assurer que l'on pouvait passer plus
d'information que $id_secteur à extra_saise(), autrement dit permettre
d'autres critères de sélection pour les champs que le secteur (non
documenté, d'ailleurs :).

Autrement dit, il faudra un changement d'interface à extra_saisie() de
toute façon. L'approche que je propose a aussi l'avantage d'être
extensible... Pour l'instant, c'est ça qui marche pour moi...

Content de voir que les discussions s'ouvre là-dessus,

A.

4

> Déjà l'#extra est si compliqué qu'on a décidé de ne pas le documenter pour
> l'instant et de le garder en alpha ; mais là on complique encore, et si je
> vois bien que c'est utile dans certains cas, on sort quand même du
cadre de
> SPIP, qui tient à avoir des objets relativement propres et une doc
> lisible...
> Peut-être que la proposition récente de faire une table d'extras
serait plus
> propre ? Il faudrait essayer d'y réfléchir... (et proposer une méthode
> migration si on franchit le pas).

Je rappelle l'expérience de Sylvain Laporte: http://elvir.univ-poitiers.fr/article.php3?id_article=556

Sinon je remarque que les champs extras sont surtout utilisés pour stocker des méta-données, c'est à dire des descripteurs et non du contenu. Je propose qu'on 'réserve' socialement (c'est à dire pas en dur dans le code, mais dans la documentation) cinq noms de champs extra et quatre types de mot clé pour la correspondance avec les champs du Dublin Core ( http://www.dublincore.org/ ). Il n'y a rien à réserver pour Title, Creator, Date, Language, Description, Identifier: ces champs sont déjà dans SPIP. Je présume que Description correspond au chapeau selon les règles de composition écrite courantes, et que Identifier est article18 par exemple.

Il s'agirait donc de réserver les types de mot-clés: Type, Format, Coverage, Subject.

Et de réserver les noms de champ extra: Publisher, Contributor, Source, Relation, Rights.

Publisher: An entity responsible for making the resource available
Examples of Publisher include a person, an organization, or a service. Typically, the name of a Publisher should be used to indicate the entity.

Contributor: An entity responsible for making contributions to the content of the resource.
Examples of Contributor include a person, an organization, or a service. Typically, the name of a Contributor should be used to indicate the entity.

Source:: A Reference to a resource from which the present resource is derived.
The present resource may be derived from the Source resource in whole or in part. Recommended best practice is to identify the referenced resource by means of a string or number conforming to a formal identification system.

Relation: A reference to a related resource.
Recommended best practice is to identify the referenced resource by means of a string or number conforming to a formal identification system.

Rights: Information about rights held in and over the resource.
Typically, Rights will contain a rights management statement for the resource, or reference a service providing such information. Rights information often encompasses Intellectual Property Rights (IPR), Copyright, and various Property Rights. If the Rights element is absent, no assumptions may be made about any rights held in or over the resource.

Dans ma liste des champs extras, je verrais bien aussi StandardNumber (ISSN ou ISBN), DOI (Digital Object Identifier) ainsi que les champs BibTeX qui manqueraient à la liste ci dessus, mais c'est moins normalisé.

Bien à vous tous,
Minh