[spip-dev] proposition d'ajout de fonctionnalites

Dev
1

Bonjour,

J'ai installe SPIP il y a quelques jours et pour mes besoins pro, j'ai du
faire quelques modifications :

J'ai cree un calendrier ...

C'est a dire :
- rajout du champs date_evt dans la base article,
- rajout des critres (evt-futur et evt-passe) et du champs #DATE_EVT dans
les boucles de type article,
- modification de article.php3 et article_edit.php3 afin de pouvoir saisir
la date.

Si la date est nulle (valeur par defaut), l'article n'apparait pas dans le
calendrier;
Si la date >= date du jour, elle apparait dans le calendrier (grace au
critere evt-futur)

http://bruno.schultz.free.fr/spip-1.3.2.dev/calendrier.php3?recalcul=oui&Sub
mit=Recalculer+cette+page

http://bruno.schultz.free.fr/spip-1.3.2.dev/calendrier.html

si la date < date du jour, elle apparait dans la liste des evts passes
(grace au critere evt-passe)
http://bruno.schultz.free.fr/spip-1.3.2.dev/evt-passe.php3?recalcul=oui&Subm
it=Recalculer+cette+page

http://bruno.schultz.free.fr/spip-1.3.2.dev/evt-passe.html

Est il possible d'integrer ces modifications dans la prochaine version ?

Si oui, comment ?

Cordialement

Bruno SCHULTZ

2

@ Schultz bruno <schultz@magic.fr> :

J'ai cree un calendrier ...

C'est a dire :
- rajout du champs date_evt dans la base article,
- rajout des critres (evt-futur et evt-passe) et du champs #DATE_EVT dans
les boucles de type article,

Si j'ai bien compris ce que tu as fait, cela existe déjà : c'est la "date de
première publication", qu'on peut avoir avec l'"interface complète".

-- Fil

3

Salut,

@ Schultz bruno <schultz@magic.fr> :

J'ai cree un calendrier ...

C'est a dire :
- rajout du champs date_evt dans la base article,
- rajout des critres (evt-futur et evt-passe) et du champs #DATE_EVT dans
les boucles de type article,

Si j'ai bien compris ce que tu as fait, cela existe déjà : c'est la "date de
première publication", qu'on peut avoir avec l'"interface complète".

je ne pense pas ...

En fait, il ne s'agit pas d'une date de 1ere publication mais de la date de
l'evenement dont parle l'article;

Exemple :

je peux ecrire le 1er juin qu'aura lieu le repas de quartier le 28 juin.
La date qui apparait dans le calendrier est "28 juin 2002" et non pas la
date de publication (1er Juin).

L'evenement apparaitra dans le calendrier jusqu'au 28 juin inclus puis
disparaitra automatiquement pour apparaitre dans la liste des evenements
passes.

Date de 1ere publication et date de l'evenement sont a mon avis deux
notions differentes ... Il est donc preferable de les separer.

A+

Bruno

4

@ Schultz bruno <schultz@magic.fr> :

je peux ecrire le 1er juin qu'aura lieu le repas de quartier le 28 juin.
La date qui apparait dans le calendrier est "28 juin 2002" et non pas la
date de publication (1er Juin).

L'evenement apparaitra dans le calendrier jusqu'au 28 juin inclus puis
disparaitra automatiquement pour apparaitre dans la liste des evenements
passes.

Date de 1ere publication et date de l'evenement sont a mon avis deux
notions differentes ... Il est donc preferable de les separer.

Ce que je voulais dire, c'est que tu disposes de deux dates par article : tu
peux utiliser la "date de première publication" (qui n'est pas "1er juin",
mais ce que tu veux bien y mettre) pour signifier "date de l'événement".

La "date de publication", elle, est la date à laquelle ton événement
commence à s'afficher (1er juin si tu fais "publier" le 1er juin, sauf si tu
la changes après pour avoir une "publication postdatée", cf. la doc).

Pour faire court : ce n'est pas parce que la deuxième date livrée avec spip
s'appelle "date de première publication" que tu ne peux pas l'utiliser pour
autre chose... pas besoin de patcher spip pour ce que tu veux faire.

-- Fil

5

Re-bonjour,

Chez CLX on utilise déjà ça, dans une rubrique particulière (agenda),
avec rappel à la une.

http://clx.anet.fr

Donc, je ne suis pas le seul a avoir ce besoin :-)))

L'astuce, une fois la brève ou l'article publié, c'est de changer la
date de publication. Les squelettes sont prévus pour afficher tous les
évènements dont la date de publication est futre, et masquer les autres.
C'est donc la même chose, sans patche.

J'avais envisagee une solution de ce type ...
Mais, mon objectif est de faire utiliser par quelques associations qui
n'ont pas de site web et peu de connaissances techniques.

C'est pourquoi, je voulais une solution TRES simple pour l'utilisateur et
qui demande le moins de manipulation possible : saisie de l'article avec la
date de l'evenement.

Ensuite, la gestion du calendrier est automatique avec le critere
'evt-futur'.

Pour faire court : ce n'est pas parce que la deuxième date livrée avec spip
s'appelle "date de première publication" que tu ne peux pas l'utiliser pour
autre chose... pas besoin de patcher spip pour ce que tu veux faire.

Oui et non ...

Je suis d'accord avec vous deux qu'il est possible de le faire mais en
"bidouillant".

Mais, comme SPIP est en GPL et que j'ai donc acces au source, je me suis
dit pourquoi ne pas
integrer directement la fonctionnalite ?

En plus, comme SPIP est developper proprement, cela n'a pas ete trop dur.

Le resultat est a mon avis plus propre ...

Je n'aime pas trop detourner l'utilisation des champs en dehors de leur
fonction d'origine :
- je suppose que ce champs a une utilité ? cela risque de creer des effets
de bord ...
- Cela demande une formation supplementaire a l'utilisateur (la date de
l'evenement, tu l'as met dans le champs 'Date de 1ere publication ... ce
n'est pas tres logique !)

En tout cas, je tiens mes ajouts a votre disposition.

Cordialement,

Bruno

PS :

je suis pret a rediger un petit texte sur ce que j'ai compris des pages
articles.php3 et article_edit.php3 pour la documentation 'technique' . Cela
vous paraitra peut etre trivial mais c'est j'ai eu besoin pour comprendre
le fonctionnement.

6

C'est vrai... Et a mon avis ta modif aura une place bien trouvé dans la
section contrib. Mais dans la mesure où ce que tu souhaites est une
utilisation détournée de SPIP, qui ne fait que gérer du contenu
éditorial, je ne pense pas que ta contrib puisse trouver sa place dans
la branche principale de spip...
Par contre, pour un "spip-agenda", c'est excellent !