Blazor Scheduler 1 : Mise en route

Le Telerik Blazor Scheduler vous permettra de créer une application qui gère tout ce que vos utilisateurs voudront faire avec les événements récurrents. Voici comment le configurer.

Le progrès Telerik Planificateur pour Blazor prend en charge en fait deux types d’événements :

Cette flexibilité vous donne beaucoup de puissance : il n’est pas difficile, par exemple, d’imaginer créer une application dans laquelle votre utilisateur génère un calendrier d’événements récurrents et doit ensuite gérer des événements individuels dans ce calendrier : annuler/supprimer des événements, modifier le titre d’un événement. ou une description, ou même déplacer un événement à une autre date (hors calendrier).

Le premier message dans les puces ci-dessus concerne une façon de gérer ce scénario : convertissez vos événements récurrents en événements individuels généré pendant un certain temps dans le futur… et abandonnez l’utilisation de l’objet de planification, au moins dans votre interface utilisateur.

Bien que cela donne à votre utilisateur une grande flexibilité dans la gestion des événements, s’il souhaite modifier l’ensemble du calendrier (par exemple, le jour de début, la fréquence de répétition de l’événement, le jour où il se produit, etc.), il devra le faire. , en fait, recommencez et récupérez l’objet de planification dans le planificateur. De plus, vous devez toujours stocker cet objet de planification quelque part afin de pouvoir générer de nouveaux événements lorsque vous arrivez à la fin de la période que vous avez choisie lors de la génération des événements.

Mais le planificateur ne vous oblige pas à le faire. Le planificateur vous permettra de générer un ensemble récurrent d’événements à l’aide d’un objet de planification, puis de laisser votre utilisateur modifier ce calendrier en modifiant ou en déplaçant les événements générés ou même en modifiant le calendrier lui-même, qui fait toujours partie de l’interface utilisateur du planificateur. Le planificateur permettra même à votre utilisateur d’ajouter de nouveaux événements aux programmes existants… et vous pourrez toujours conserver votre programme d’origine pour générer des événements aussi loin que vous le souhaitez.

Avant de commencer sur la façon de procéder, quelques termes. J’appellerai tout ce qui se trouve dans l’interface utilisateur de Scheduler un « événement ». Mais, pour distinguer les différents types d’événements dans un planning, je commencerai par faire référence à :

• Occurrences : Événements générés à partir d’un objet de planification qui se produisent « dans les délais »
• Exceptions : Événements qui font partie du calendrier, mais qui ont été modifiés (par exemple, déplacés vers une nouvelle date, dotés d’un titre ou d’une description distincts)

Et il ne s’agit pas seulement de terminologie : il existe ici une distinction importante au niveau du codage.

L’interface utilisateur du planificateur est pilotée par une liste dans son Data propriété qui contient à la fois des objets de planification et des objets d’exception. Occurrences (c’est-à-dire, événements régulièrement programmés se déroulant exactement dans les délais) ne le faites pas apparaître dans cette liste. Les exceptions (événements qui ont été modifiés) apparaissent dans cette liste. Cela signifie que votre code pour gérer les événements régulièrement programmés qui n’ai pas été modifié (c’est-à-dire les occurrences) sera différent du code fonctionnant avec des événements « modifiés » (c’est-à-dire les exceptions).

Je vais également commencer à faire référence à cette liste d’objets dans le planificateur Data propriété comme « la liste de données » par opposition à « la liste qui pilote le planificateur » (et ce n’est que de la terminologie).

Encore une chose : comme je l’ai expliqué dans des articles précédents sur les planifications récurrentes, vous souhaiterez partager les événements affichés dans le planificateur avec d’autres applications ou systèmes en enregistrant ces événements dans une base de données (à la fois les exceptions dans la liste de données et les exceptions générées). occurrences qui ne figurent pas dans cette liste. Dans le cadre de cette étude de cas, je suppose que vous ne mettrez pas à jour votre base de données en temps réel (c’est-à-dire que vous ne supprimerez pas les occurrences de votre base de données lorsque votre utilisateur les supprimera de la planification), même si vous pourrait fonctionner en temps réel.

Au lieu de cela, je vais supposer que vous donnerez à votre utilisateur un bouton Enregistrer qui renverra toutes les modifications de l’utilisateur dans la base de données lorsque l’utilisateur aura fini de mettre à jour le calendrier. Cette approche vous permet également d’implémenter une option « annuler » afin que l’utilisateur puisse ignorer l’enregistrement de ses modifications.

Ce flux de travail permet non seulement de permettre à l’utilisateur de se retirer d’un ensemble de modifications malheureuses. Il permet également à votre utilisateur d’expérimenter le calendrier de votre application : ajout/suppression d’événements, modification du moment où les événements se reproduisent, etc. Pour prendre en charge ce type de mise à jour différée, vous devrez suivre vos modifications au fur et à mesure que votre utilisateur les apporte afin que vous puissiez peut valider ces modifications dans votre base de données lorsque l’utilisateur clique sur le bouton Enregistrer.

Dans cet article, je vais aborder tout ce que vous devez faire pour configurer Scheduler, puis, dans les articles suivants, examiner tout ce qui est impliqué dans la gestion des événements récurrents de Scheduler.

Définir les données

Vous aurez besoin d’un objet qui fera à la fois office de :

• Objet de planification : Il s’agit d’une classe qui a un horaire récurrent dans Format RFC5545/iCalendarainsi que le titre et la description des occurrences générées à partir de cette planification. J’ai discuté de ce format dans mon publier sur des événements récurrents.
• Objet d’exception : Il s’agit d’une classe qui représente une exception à cette planification : une occurrence qui a été déplacée vers une date/heure « hors planification » ou dont le titre ou la description a été modifié par rapport à ce qui est défini dans l’objet de planification.

Vous n’avez pas besoin de créer des classes distinctes pour ces deux objets (en fait, je dirais qu’il est plus facile de gérer le planning si vous utilisez une seule classe pour les deux). Le résumé de Telerik Appointment class définit un objet événement qui sert de base à une classe d’événement. En utilisant le Appointment objet en tant que classe de base vous permet d’ajouter vos propres propriétés spécifiques à l’application à cette classe (bien que le Appointment la classe a aussi un DataItem propriété où vous pouvez insérer un autre objet associé et spécifique à l’application).

Pour étendre cette classe afin qu’elle puisse également agir comme un objet de planification, il vous suffit d’ajouter une propriété de chaîne pour contenir la planification RFC5545 que le planificateur utilise pour générer des événements.

Vous voulez vous assurer que tous les objets créés à partir de cette classe ont toujours une valeur attribuée à leur propriété Id. Vous pouvez toujours attribuer cette valeur au Id propriété vous-même dans votre code, mais il est plus facile de donner à votre classe un constructeur qui met une valeur unique dans le champ de l’objet. Id propriété chaque fois qu’un nouvel objet est créé.

Ainsi, pour cette étude de cas, l’objet planning/exception que je vais utiliser s’appelle BillingPlan et ressemble à ceci :

class BillingPlan: Appointment
{        
    BillingPlan()
    {
        Id = Guid.NewGuid();
    }
    string RecurrenceRuleString { get; set; } = string.Empty;
}

Le planificateur Data la propriété doit être définie sur une liste de vos objets de planification/exception, j’ai donc défini un champ pour contenir une liste de BillingPlan objets : la liste de données pour cette étude de cas :

 IList<BillingPlan> DataList = new List<BillingPlan>();

Pour que Scheduler génère une liste d’occurrences pour mon étude de cas, il me suffit d’ajouter un objet de planification/exception (c’est-à-dire un BillingPlan object) avec sa propriété RFC5545 définie sur mon planning récurrent. Dans la vraie vie, vous récupérez cet objet de votre base de données (comme je l’explique, à un niveau élevé, dans le dernier article de cette série). Pour cette étude de cas, je vais simplement créer un objet factice et l’ajouter à la liste de données (pour une discussion de ce qui se passe ici, voir mon article précédent sur la création de récurrences) :

protected override void OnAfterRender(bool firstRender)
{
    IList<DateTime> FutureDates = new List<DateTime>();
    if (firstRender)
    {
        BillingPlan bp = new();

        bp.DataItem = new Customer("A123", "FREQ=Weekly");
       bp.RecurrenceRuleString = ((Customer)this.DataItem).PaymentSchedule;
       bp.RecurrenceRule = RecurrenceRule.Parse(RecurrenceRuleString);

        bp.Title = "Billing for A123";
        bp.Start = DateTime.Now.Date;
        bp.End = DateTime.Now.Date.AddSeconds(1);
        bp.IsAllDay = false;
        DataList.Add(bp);
    }
    base.OnAfterRender(firstRender);
}

Configuration du planificateur

La configuration de Scheduler pour générer et gérer des événements récurrents nécessite que vous définissiez trois propriétés :

• Données: Définir sur votre liste de données d’objets de planification et d’exception
• Champ de règle de récurrence : Définissez sur le nom de la propriété de votre objet événement qui contient votre planning au format RFC5545.
• Autoriser la mise à jour : Défini sur true pour permettre à l’utilisateur d’ajouter, de modifier et de supprimer des exceptions aux occurrences de la planification

En conséquence, un planificateur configuré pour permettre à votre utilisateur de gérer des événements récurrents ressemble à ceci :

<TelerikRootComponent>
    <TelerikScheduler 
                      Data="DataList"
                      RecurrenceRuleField="RecurrenceRuleString"

                      AllowUpdate="true">

Lorsque votre application s’ouvre, à condition que vous ayez un objet de planification dans la liste de données, le planificateur remplira son interface utilisateur avec des occurrences (événements générés à partir de la planification RFC5545).

Vous pouvez maintenant commencer à penser, par exemple, à permettre aux utilisateurs de modifier la planification ou de créer des exceptions aux occurrences régulièrement planifiées. C’est le sujet de mon prochain post.

Vous souhaitez l’essayer vous-même ? L’interface utilisateur Telerik pour Bibliothèque de composants Blazor est livré avec un essai gratuit de 30 jours.

Essayez maintenant