Gestion des évènements répétitifs


Afin de limiter les messages d'avertissements et les questions posées à l'utilisateur, certains principes vont être mis en place.

Les exemples se basent sur un évènement hebdomadaire "Réunion d'équipe" : * Le changement de statut d'un évènement répétitif ne concerne que l’occurrence sélectionnée. Cette surcharge déclenche donc une instanciation implicite. Exemple : si la réunion de cette semaine est annulée, le changement de statut ne concerne à priori que cette occurrence. (S'il est besoin de modifier le statut de l'ensemble des occurrences, cela restera possible via une édition.) * Lors de l'édition, l'utilisateur doit donc préciser s'il veut modifier l'ensemble des occurrences ou seulement celle qui est sélectionnée. S'il choisit de modifier l'ensemble des occurrences, la modification n'impactera pas celles qui sont déjà surchargées. (Un code visuel permettra de distinguer dans la liste les évènements répétitifs des uniques, donc un évènement répétitif surchargé sera identifiable par son caractère unique.)

* La suppression déclenche également une question sur sa portée.
- Contrairement à l'édition, une demande de suppression de l'ensemble des occurrences résultera bien en la supression de toutes les occurrences, y compris celles qui ont été surchargées ou sont déjà passées. S'il s'agit de mettre fin à l'évènement répétitif, il vaudra donc mieux spécifier une date de fin.
- Dans le cas où seulement l'occurrence sélectionnée doit être supprimée, elle ne le sera pas. A la place, elle sera surchargée - si elle ne l'était pas déjà - et son statut sera passée à "Annulée". La conserver annulée permettra de faire marche arrière si besoin, car l'effacer permettra à nouveau de "voir" à nouveau l'évènement répétitif. Ce principe de conserver un évènement annulé sera également utilisé pour un changement de date. Par exemple, si la réunion hebdomadaire est reportée du mardi au jeudi cette semaine, l'utilisateur va l'éditer, choisir une modification locale, et modifier la date. Le système va créer un évènement unique pour le jeudi, mais également une annulation pour le mardi. Pour rétablir l'état initial, l'utilisateur devra manuellement supprimer les deux évènements. Si l'évènement répétitif est en plus modifié du mardi au mercredi, le système va laisser l'annulation du mardi et affichera une nouvelle occurrence pour le mercredi. Il va falloir jouer un peu avec pour s'y faire, car le système n'aura pas d'intelligence, il saura seulement créer automatiquement des surcharges quand il faudra modifier ou masquer ponctuellement un évènement répétitif.

Suppression


La suppression des différents types d'évènements fonctionne.


Lors de l'instanciation d'un évènement répétitif, son identifiant est conservé dans la PropertyList de l'instance surchargée : Cet identifiant sert à effacer toutes les instances lors de la suppression définitive de l'évènement répétitif.
Le service qui permettait de chercher un objet dans un arbre de données selon son identifiant a du être amélioré. Il est donc désormais capable de chercher dans les valeurs stockées à l'intérieur des Properties.

(A noter la nouvelle structure des dossiers techniques : les évènements répétitifs sont désormais stockés dans leur propre dossier SuperEvents, et les dossiers techniques Index ont été renommés en Week, maintenant au format ISO 2013-W04.)


Nous avons maintenant la création, la modification, le changement de statut et la suppression.
Prochaines étapes : monter et descendre puis couper, copier, coller et les déplacements entre dossiers et dates.

Positionnement


La possibilité de positionner des évènements (les monter ou descendre dans la liste) est pour le moment descopée car trop complexe.

On n'est pas en WYSIWYG, car la liste des données affichées est le résultat de plusieurs opérations :
- Si on est en mode "semaine" : une première boucle sur les dates.
- Une possible récursivité sur les dossiers si on est en vue étendue (dossier sélectionné et ses sous-dossiers).
- Une boucle sur les types de données : périodes, évènements et tâches, puis sur les données elles-mêmes, les évènements uniques datés étant rangés dans des dossiers d'indexation par semaine.
- Une instanciation temporaire des évènements répétitifs.
- Un filtre sur les évènements répétitifs pour vérifier qu'ils sont activable sur cette date.
- Un filtre sur les évènements répétitifs qui ont été surchargés.
Tout ce travail est réalisé dans une structure intermédiaire dédiée. Les évènements sans heures y sont stockés séparément de ceux avec car seuls ces derniers sont triés avant affichage.

Bref, cela fonctionne, mais faire le chemin inverse afin de modifier l'ordre des données est pour le moment hors de portée.

En effet, cela n'a pas l'air simple....

Sinon, ton XML, dommage d'avoir des balises <prop>truc=valeur</prop>. Pourquoi pas directement des balises <truc>valeur</truc>?

DMo a écrit :En effet, cela n'a pas l'air simple....

Sinon, ton XML, dommage d'avoir des balises <prop>truc=valeur</prop>. Pourquoi pas directement des balises <truc>valeur</truc>?

Bonne question. Je n'y ai jamais trop fait attention, mais il faudra que je refasse une passe, car je crois que certains outils stockent des valeurs seules dans la TStringList qui est mappée vers ces <Prop>. Mais je crois que l'ajout de la seconde TStringList "Text" devait justement les stocker... C'est vrai qu'il y a du gâchis, et c'est pas beau, je note donc ça dans ma liste de tâches, thanks.

En fait c'est Text qui est supposé contenir du texte libre (le futur Bloc-notes) mais peut contenir des propriétés définies par l'utilisateur.

Les Properties sont toujours du format "Nom=Valeur" et seront donc balisées.