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",
) ;