Carnet Wiki

UnAgendaPourSPIP

EVENEMENTS

James_Spip en fait, faut savoir si tous les articles d’un spip seront évènementiels ou si un article sera ’typé’
Cedric_
et le type la est pas pertinent pour l’application visee
Cedric_
non c’est pas obligatoire pour un article d’etre evenementiel
James_Spip
les types, c’est un peu comme pour les documents ... faut y penser judicieusement
Cedric_
mais a priori pas plus d’un article par evenement
James_Spip
donc, une autre table avec un lien id_article, ça me semble idéal, non ?
Cedric_
mais je sens qui si ca prend bien, on va vite vouloir aussi des breves par exemples
Cedric_
et la vaut mieux utiliser des tables relationelles du coup oui
James_Spip
si ton évènement est périodique, il peut retrouver le même article à afficher, ça me choque pas
James_Spip
ne tombe pas dans le panneau
Cedric_
ah oui voila c’est ca qui manque
James_Spip
les brèves, si ça marche bien, faudra des auteurs
James_Spip
les brèves, si ça marche bien, faudra des doc joints
Cedric_
un champ id_evenement_source
Cedric_
pour les repetitions des evenements periodiques
Cedric_
ou sinon le type je le fait sauter
James_Spip
une période, en bdd c’est quoi ? un nombre et une unité de temps
Cedric_
et on utilisera un groupe de mot cle au choix
James_Spip
ça me paraît plus simple aussi... comme le lieu de l’évènement
Cedric_
je pensais pas gerer les periodicité explicitement dans la bdd
Cedric_
mais par clonage de l’evenemnt source
Cedric_
vu que y a que des trucs zarbi en repetition d’evenement
Cedric_
genre tous les 1er mercredi du mois
Cedric_
tout les jours sauf le mercredi
James_Spip
en effet, celui-là, c’est coton
Cedric_
donc c’est par l’interface qu’on fixera les repetitions
James_Spip
mais bon, d’abord simple : une période simple
James_Spip
j’avais imaginé un truc du genre répétition : 1=une seule fois, 0=iinfini, X=répété X fois
James_Spip
je jette des idées, mais c’est mal dégrossi hein
Cedric_
oui je vois ce que tu veux dire
James_Spip
autre hypothèse, on s’appuie pas sur la date de publication, ni sur la date de rédaction, mais bien sur 1 autre date (dans la table évènement) qui serait la date de l’évènement
Cedric_
oui oui c’est ca que je fais la
James_Spip
super
Cedric_
une date_debut et date_fin independantes des dates de publi de l’article
Cedric_
l’autre raison pour laquelle je prefere cloner les evenements pour gérer les repetitions
James_Spip
après pour définir la durée, je ne sais pas si c’est la date de fin qu’il faut conserver en base ou bien définir une durée (1 nombre, une unité de temps) ...
Cedric_
c’est de pouvoir modifier le descriptif ou le lieu pour une occurence seulement
James_Spip
modif à postériori, pourquoi pas en effet
Cedric_
ou transformer une occurence en evenement indépendant
Cedric_
ou genre tu fais repeter toutes les semaines
Cedric_
puis la semaine 23, tu deplace du mercredi au jeudi
Cedric_
parce que cette semaine la c’est pas pareil
Cedric_
ca permet plein de souplesse en fait
James_Spip
bé oui, j’imagine
Cedric_
sinon date_fin ou durée oui, les deux sont possibles
James_Spip
peut-être que c’est une fausse question hein
Cedric_
mais comme la j’ai deja pas mal de pieces du puzzle qui tournent avec date_fin
James_Spip
on aura besoin de quoi le plus souvent dans un squelette ?
Cedric_
je crois que je prefere pas y toucher sauf gros argument pour
James_Spip
une balise #DUREE ?
Cedric_
oui la balise on peut l’ajouter facilement en fait
James_Spip
je pensais ausi à des critères
James_Spip

Cedric_
oui il faut ce genre de critere
Cedric_
pour chercher les evenement en cours a une date donnée
James_Spip
donc, la avec date_fin, c’est plus simple et performant je suppose ?
Cedric_
c’est souvent lui dont on a besoin oui
James_Spip
et le clonage aussi simplifie l’écriture du code ...
Cedric_
oui, ca deporte le pb dans l’interface
Cedric_
et c’est moins structurant
Cedric_
bon sinon EVENEMENTS pour les boucles c’est causant non ?
James_Spip

sinon, si vraiment tu y tiens, pour identier la source (l’objet éditorial) tu prend un couple (id_objet, type_objet) comme ça hop
Cedric_
oui maus je vais plus m’embeter pour generer le #ID_ARTICLE apres
Cedric_
alors que par la table relation c’est plus conventionnel
James_Spip
si on a une table spip_evenements, une boucle EVENEMENTS c’est sur, ça peut être sympa
Cedric_
oui bon je pars la dessus
Cedric_
je garde AGENDA pour des fonctions plus typées agenda perso/organisation du temps
James_Spip
par contre, attention, spip_evenements, c’était utilisé dans spip_notifications ... je sais pas comment se sera rerpris
Cedric_
:-)

James_Spip t’as laissé un champ lieu dans la déclaration de la table evenements
Cedric_ oui
Cedric_ j’aime bien la possibilité de garder un champ libre pour ca
Cedric_ j’hesite vraiment a le supprimer
Cedric_ par contre je me demande si je met aussi un lieu evenement-auteur
Cedric_ un lien evenement-auteur
Cedric_ en fait ou pourrait aussi vouloir ajouter des evenement
James_Spip mais dans ce cas, autant virer id_source_evenement et créer carrément un nouvel objet éditorial non ?
Cedric_ qui ne soient pas lies a un article
James_Spip oui
James_Spip c’est ça
James_Spip un truc autonome quoi
Cedric_ et qui renvoient vers une url
Cedric_ oui que ce soit autonome, meme si l’utilisation principale est avec un article
Cedric_ le id_source_evenement c’est pour referencer l’id_evenement maitre, pour les clones
James_Spip ok
Cedric_ bon, donc en fait faut aussi un champ url
James_Spip comme pour les breves et eles articles, oui
James_Spip sinon, c’est calculé
Cedric_ puis la en copiant les champs nom_site/url_site, je voie url_propre
Cedric_ pareil il en faut un donc
James_Spip et un titre
Cedric_ oue et si on va par la un statut
Cedric_ :-(
James_Spip hé hé
Cedric_ bon ...
Cedric_ reflechissons bien ...
l j’hesite vraiment entre le choix ’objet d’horodatage lie a un objet editorial’
Cedric_ et ’objet editorial a part entiere, lie a d’autres objets eventuellement’
James_Spip idem
James_Spip ce qui m’intéresse dans le premier cas
James_Spip c’est que ça reste des articles qu’on peut traiter comme les autres, voire avec les autres
Cedric_ parce que pour annoncer tout un tat d’evenements simple qui tiennent en une ligne, faire un article c’est lourd
Cedric_ genre vide-grenier a trifouilly le 23.03.2006
James_Spip bof ... est-ce que c’est grave ?
Cedric_ non, c’est pas grave, c’est juste plus lourd ...
Cedric_ en meme temps sinon on va disperser l’info
Cedric_ dans les articles ET dans les evenements
l’avantage aussi, c’est que tu transforme un article en évènement en deux coup de cuillère à pot
James_Spip et inversement
James_Spip comme pour activer/désactiver une pétition, justement
Cedric_ oui
Cedric_ tu sors l’info de l’agenda sans la perdre
James_Spip l’indexation, l’asso de mots-clés, les auteurs, tout est déjà là
James_Spip et tu n’ajoute pas d’interface de saisie supplémentaire, si ce n’est un sélecteur un peu smart
Cedric_ bon, donc pour mettre un evenement dont l’info est distante on utilise un article virtuel
James_Spip grâce au point d’entrée qu’on va ajouter
James_Spip en plus
Cedric_ oui, enfin du point de vue saisie, je veux qu’on puisse aussi travailler a partir d’une interface de type calendrier
Cedric_ sur laquelle on a une vue synthetique temporelle
Cedric_ de tous les evenements
Cedric_ mais c’est du detail ca :-)
Cedric_ bon allez adjuge vendu
James_Spip et puis y a déjà des trucs de fait :)
Cedric_ pas de champs nom_site/url_site/url_propre
Cedric_ et pas de lien auteur
Cedric_ les droits sont herites de l’objet lie
Cedric_ soit pour le moment un article

Structure de la table

//-- Table EVENEMENTS ------------------------------------------
_ $evenements = array(
_                 "id_evenement"        => "bigint(21) NOT NULL",
_                 "date_debut"        => "datetime DEFAULT '0000-00-00 00:00:00' NOT NULL",
_                 "date_fin"        => "datetime DEFAULT '0000-00-00 00:00:00' NOT NULL",
_                 "titre"        => "text NOT NULL",
_                 "descriptif"        => "text NOT NULL",
_                 "lieu"        => "text NOT NULL",
_                 "id_evenement_source"        => "bigint(21) NOT NULL",
_                 "idx"                => "ENUM('', '1', 'non', 'oui', 'idx') DEFAULT '' NOT NULL",
_                 "maj"        => "TIMESTAMP"
_                 );

_ $evenements_key = array(
_                 "PRIMARY KEY"        => "id_evenement",
_                 "KEY date_debut"        => "date_debut",
_                 "KEY date_fin"        => "date_fin",
_                 );
Cerdic , James - Mise à jour :12 May 2012 at 16:44