[spip-dev] id_secteur pour la table spip_forum

Bonjour à tous,

  Il y a un critère id_secteur qui existe dans la boucle FORUMS mais qui ne semble pas être implémenté. Je me demandais si je pouvais m'en occuper d'une part et si j'avais une vision claire de la façon de s'y prendre d'autre part.

  Donc il s'agirait :

1- ajouter une colonne id_secteur dans la table spip_forum
2- modifier le code de inc-forum.php3 et inc-messforum.php3 et peut-être d'autres, je n'ai pas encore regardé en détails, pour ajouter le id_secteur.
3- Il faut aussi écrire le code de mise à jour de la base de donnée lors de l'installation sur une ancienne version

Question :

Faut-il embarquer ce id_secteur dans le formulaire du forum ou bien suffirait-il de l'insérer au dernier moment lorsque le message est validé ?

Cordialement

@ Jean-Luc Béchennec <jean-luc.bechennec@irccyn.ec-nantes.fr> :

  Il y a un critère id_secteur qui existe dans la boucle FORUMS mais
  qui ne semble pas être implémenté. Je me demandais si je pouvais m'en
occuper d'une part et si j'avais une vision claire de la façon de s'y
prendre d'autre part.

  Donc il s'agirait :

1- ajouter une colonne id_secteur dans la table spip_forum
2- modifier le code de inc-forum.php3 et inc-messforum.php3 et
peut-être d'autres, je n'ai pas encore regardé en détails, pour ajouter
le id_secteur.
3- Il faut aussi écrire le code de mise à jour de la base de donnée
lors de l'installation sur une ancienne version

Question :

Faut-il embarquer ce id_secteur dans le formulaire du forum ou bien
suffirait-il de l'insérer au dernier moment lorsque le message est
validé ?

id_secteur, mais aussi peut-être et surtout id_thread ?
Il y a une discussion là-dessus là (à laquelle tu participes)
http://www.spip-contrib.net/spikini/index.php?wiki=SpipForum

Où est noté : "Déesse-A prétend que son compilateur réglera entièrement et
nativement ce problème... wait and see ?"

Donc ?

-- Fil

Je souhaiterais conserver le monopole de ma propre parole,
et donc qu'on ne me fasse pas dire ici ou là des choses qui ne sont peut-etre pas fausses,
mais qui pourraient faire croire que je m'engage à des choses dont je n'ai pas encore mesuré l'ampleur.
Merci d'éliminer cette remarque, en attendant que je comprenne de quoi il s'agit précisément.

En attendant, j'ai commencé à regarder le pb d'id_doublon dans inc_documents.
Ca me parait gérable dans l'architecture actuelle, mais à nouveau une chose me stupéfactionne:
ligne 1253 on affecte le résultat d'un appel de propre à une variable $pour_documents_doublons
qui n'est utilisée nulle part. De son côté, propre ne semble pas (extraordinaire) affecter de
variables globales ni effectuer de choses irréversibles de ce genre. Caisse à dire ?

esj

PS: Fil, merci pour l'URL masquée

Merci d'éliminer cette remarque

ok

En attendant, j'ai commencé à regarder le pb d'id_doublon dans
inc_documents. Ca me parait gérable dans l'architecture actuelle, mais à
nouveau une chose me stupéfactionne: ligne 1253 on affecte le résultat
d'un appel de propre à une variable $pour_documents_doublons
qui n'est utilisée nulle part. De son côté, propre ne semble pas
(extraordinaire) affecter de
variables globales ni effectuer de choses irréversibles de ce genre.

Dans ecrire/inc_documents.php3 :

function embed_document($id_document, $les_parametres="",
$afficher_titre=true) {
        global $id_doublons;
        $id_doublons['documents'] .= ",$id_document";

etc. etc.

Quand on parle de "la fonction propre()", c'est quand même pas juste une
fonction toute bête, mais un gros plat de spaghettis.

PS: je supprime spip_fetch_object() de la liste des fonctions supportées
officiellement, et j'élimine le code officiel qui y fait référence ; il
faudra tester le calendrier (ça marche chez moi, mais j'ai peut-être oublié
un truc).

-- Fil

Je me suis mal exprimé.

Il y a des endroits où figure un appel à propre dont le résultat est affecté à une variable
de patronyme "doublon" mais qui n'est pas réutilisée ensuite:
- ligne 1253 de inc_documents
- ligne 54 de breves_edit
le seul rapport entre les doublons et cette fonction "propre" serait qu'elle affecte des globales
en rapport avec les doublons, mais il ne semble pas que cela soit le cas.
Je demande donc éclaircissements là-dessus.

Ensuite ligne 47 de articles, il y a une initialisation de id_doublons qu'inc_documents affecte ensuite
dans embed_document et autres, ça j'ai bien vu. Maintenant ce qui me surprend, c'est que ce nom "$id_doublons" est certes le même que celui du vieux compilateur, mais, étant dans l'espace privé,
je m'interroge sur le rapport réel avec le bug dénoncé.

Emmanuel

Il y a des endroits où figure un appel à propre dont le résultat est
affecté à une variable
de patronyme "doublon" mais qui n'est pas réutilisée ensuite:
- ligne 1253 de inc_documents
- ligne 54 de breves_edit

Ah oui : c'est une astuce idiote permettant d'éviter qu'un document qui se
référence lui-même, en mettant <docxx|left> à l'intérieur de son descriptif,
génère une boucle infinie. Il faudrait réécrire ça :

        // Eviter les boucles infinies en générant "doublons" sur moi-même
        $rien = propre($descriptif.texte);

le seul rapport entre les doublons et cette fonction "propre" serait
qu'elle affecte des globales en rapport avec les doublons, mais il ne
semble pas que cela soit le cas. Je demande donc éclaircissements
là-dessus.

Pourquoi trouve-t-on ce code dans breves_edit, ça par contre je ne sais
pas...

Ensuite ligne 47 de articles, il y a une initialisation de id_doublons
qu'inc_documents affecte ensuite dans embed_document et autres, ça j'ai
bien vu. Maintenant ce qui me surprend, c'est que ce nom "$id_doublons"
est certes le même que celui du vieux compilateur, mais, étant dans
l'espace privé, je m'interroge sur le rapport réel avec le bug dénoncé.

Le bug vient d'une spécification : deux cas différents :

        <BOUCLE_article(ARTICLES){id_article}>
        <BOUCLE_doc(DOCUMENTS){id_article}>
        ...

ça doit afficher tous les documents liés à l'article, qu'ils soient ou non
inclus dans le texte ;

        <BOUCLE_article(ARTICLES){id_article}>
        #TEXTE
        <BOUCLE_doc(DOCUMENTS){id_article}>
        ...

idem

        <BOUCLE_article(ARTICLES){id_article}>
        #TEXTE
        <BOUCLE_doc(DOCUMENTS){id_article}{doublons}>
        ...

ne doit afficher que les documents pas déjà inclus dans le #TEXTE de l'article.

Et {mode=document} permet de ne pas avoir les vignettes. Tout ça est assez
bordélique, j'en conviens :slight_smile:

-- Fil

Il y a des endroits où figure un appel à propre dont le résultat est
affecté à une variable
de patronyme "doublon" mais qui n'est pas réutilisée ensuite:
- ligne 1253 de inc_documents
- ligne 54 de breves_edit

Ah oui : c'est une astuce idiote

moi, les idioties ... :slight_smile:

ce nom "$id_doublons"
est certes le même que celui du vieux compilateur, mais, étant dans
l'espace privé, je m'interroge sur le rapport réel avec le bug dénoncé.

Le bug vient d'une spécification : deux cas différents :

        <BOUCLE_article(ARTICLES){id_article}>
        <BOUCLE_doc(DOCUMENTS){id_article}>
        ...
Tout ça est assez bordélique, j'en conviens :slight_smile:

ma question n'était pas là, mais je crois que j'ai fini par y répondre tout seul:
lorsque inc-documents est chargé par inc-calcul, $id_doublons référence
la variable globale anciennement mise en pile dans le vieux inc-calcul,
tandis que s'il est chargé par ecrire/articles.php3 il référence la globale
homonyme (mais qui n'a en fait rien à voir) initialisée ligne 47.
Bref, si c'est bien ça, il y avait un cas d'école de paramètre à passer,
mais non, on met une globale. Faudrait vraiment vous faire désintoxiquer les copains.

Bon, ce qui m'ennuie surtout c'est l'appel récursif en cas d'audio, ça facilite pas le boulot.

Emmanuel

Bref, si c'est bien ça, il y avait un cas d'école de paramètre à passer,
mais non, on met une globale. Faudrait vraiment vous faire
désintoxiquer les copains.

Oui, c'est pas très professionnel ce SPIP.

-- Fil

Chuis d'accord, faudrait embaucher quelques consultants.
(et puis tout réécrire en Java)

Et en plus ce n'était même pas une vraie récursion !
Enfin, tant mieux le bug a demandé finalement peu de modifs.

esj

> > Bref, si c'est bien ça, il y avait un cas d'école de paramètre à

passer,

> > mais non, on met une globale. Faudrait vraiment vous faire
> > désintoxiquer les copains.
>
> Oui, c'est pas très professionnel ce SPIP.

Chuis d'accord, faudrait embaucher quelques consultants.
(et puis tout réécrire en Java)

Je m'insurge !
Y a des gars qui ont ecrit consultant sur mes cartes de visite, je developpe
en java, et j'arrive des fois à faire bien pire !
:wink:

Et pis en java (J2EE), on a les scopes application / session / request, ben
c'est pareil, on finit toujours par mettre les variables un "scope trop
haut" pour une bidouille de retour en cas d'erreur ou autre.

La "belle programmation" n'est malheureusement pas liée au langage, ca se
saurait ....