Création d’outils pour Telerik Scheduler pour Blazor

Le code d’emballage dans des objets réutilisables peut vous faire gagner du temps – si vous prenez les bonnes décisions de conception. Voici une étude de cas pour créer des outils qui fonctionnent avec le planificateur Telerik pour Blazor.

Après avoir écrit une tonne de code, vous vous rendez compte que vous pouvez l’emballer comme un objet réutilisable et ne plus jamais avoir à rédiger ce code. Voici quelques conseils sur le fait de faire cela, avec une étude de cas pour créer des outils pour travailler avec les progrès Telerik UI pour Blazor Planificateur.

Dans les articles précédents sur le travail avec des événements récurrents dans le progrès de la télérik pour l’interface utilisateur pour Planificateur de blazorJ’ai esquissé le type de code qui vous permet de créer une application avec Scheduler qui permet aux utilisateurs de modifier les horaires, de remplacer les événements planifiés, d’ajouter de nouveaux événements et même d’ajouter de nouveaux horaires (voici le premier message dans cette série).

Bien sûr, la prochaine étape pour tout développeur serait de regrouper ce code dans un ensemble d’objets réutilisables qui simplifieraient le travail avec le planificateur dans la prochaine application. L’objectif serait de pouvoir configurer toutes les fonctionnalités de Scheduler comme ceci:

<TelerikScheduler
  Data="DataList"
  RecurrenceRuleField="RecurrenceRuleString"
  
  AllowUpdate="true"
  AllowCreate="true"
  AllowDelete="true"

  OnDelete="@DeleteSchedule"
  OnUpdate="@UpdateSchedule"
  OnCreate="@CreateSchedule">

  …other settings…
</TelerikScheduler>

Et puis soutient que toutes ces fonctionnalités avec quelque chose comme ces cinq lignes de code:

List<RecurringEvent> DataList;
SchedulerManager<RecurringEvent> sm = new() { AddSchedule = true };

void DeleteSchedule(SchedulerDeleteEventArgs e) { sm.DeleteSchedException(e); }
void UpdateSchedule(SchedulerUpdateEventArgs e) { sm.UpdateExceptionSched(e); }
void CreateSchedule(SchedulerCreateEventArgs e) { sm.CreateExceptionSched(e); }

Et tout cela est très réalisable – il y a des liens vers les objets que j’ai utilisés ici (RecurringEvent et SchedulerManager) Dans ce post pour le prouver. Mais ce projet pourrait facilement se transformer en un exemple long de la «maladie du développeur»: si elle peut être codé, puis il doit être codé.

Non, ce n’est pas le cas.

En fait, s’il y a un mantra à utiliser comme guide dans la création d’objets réutilisables, c’est ceci: vous créez des objets réutilisables pour rendre votre et votre équipe plus productives à l’avenir en gérant les «tâches typiques» dans les applications que vous pourriez créer pour votre Organisation à l’avenir. «Tâches typiques», dans ce cas, être une tâche qui nécessiterait autrement le code de répétition que vous avez déjà écrit dans le suivant application.

Ce que tu es pas Faire est de créer un produit commercial pour soutenir tout développeur créant toute application dans toute organisation.

Ainsi, mon objectif dans ce post est d’examiner le type de décisions de conception que vous pourriez prendre pour créer des objets réutilisables, et non pour fournir un ensemble d’objets de support universels pour le planificateur. Le code, bien que je sois sûr, fonctionne, est ici comme un exemple de ce à quoi ressemblent les résultats de ces décisions.

La classe RecurringEvent

Par exemple, Scheduler a besoin d’une liste d’objets d’événement pour se lier, et travailler avec Scheduler consiste à manipuler cette liste d’objets d’événement. En créant un ensemble de code réutilisable, je ne veux pas prendre en charge le travail avec un objet possible – ce serait une tâche beaucoup trop importante. Ma première décision de conception est donc de concevoir le seul objet avec lequel mon code fonctionnera.

Dans ce cas, j’ai créé une classe appelée RecurringEvent que je pouvais modifier au besoin pour prendre en charge le code que j’écrivais. Pour simplifier encore plus cette classe, je l’ai fait hériter du résumé de Telerik Appointment Classe, qui a toutes les propriétés dont le planificateur a besoin.

Maintenant, après avoir créé cette classe, je peux également l’étendre si nécessaire pour prendre en charge le code réutilisable que j’écrirai et gérerai toutes les tâches typiques. Par exemple, j’ai ajouté ces membres à mon RecurringEvent classe:

• Un constructeur par défaut: Ce constructeur aide à définir chaque RecurringEvent objet Id propriété à un GUID unique. Cela élimine la nécessité de définir le Id propriété lors de la génération d’objets d’événement.

• Récurrencélestring: Il s’agit d’une représentation de chaîne du calendrier (au format RFC5545) et est requise par le planificateur. Ma mise en œuvre de cette propriété donne non seulement à le planificateur ce qu’il veut, mais définit également la classe de rendez-vous de base RecurrenceRule propriété (utilisée lors de la génération d’événements futurs) à mettre à jour chaque fois RecurrenceRuleString est modifié de sorte que les deux propriétés sont toujours synchronisées.

• RécurrenceException: Le planificateur supprime régulièrement les occurrences planifiées pour tout événement ajouté aux objets de planification RecurrenceExceptions Propriété – Je devrai enregistrer cette liste d’exceptions dans n’importe quelle base de données qui contient mon horaire. Pour soutenir cela, le RecurrenceExceptionsString la propriété renvoie le RecurrenceExceptions Array en tant que chaîne délimitée par virgule pour un stockage facile. De même, lors de la récupération d’un objet de planification de ma base de données, je voudrais recharger mon RecurrenceExceptions propriété de cette chaîne, et mon RecurrenceExceptionsString la propriété prend en charge le fait de faire cela.

• Générer des chèques: Pour partager un calendrier avec d’autres applications, je devrai stocker les événements régulièrement programmés dans une base de données. Cette méthode contient le code pour renvoyer une liste de RecurringEvent objets pour chaque événement généré entre le calendrier Start Et le calendrier OriginalEnd date

Et c’est génial… mais il est raisonnable de supposer que toute application future qui utilise le planificateur va probablement nécessiter des propriétés supplémentaires spécifiques à l’application qui RecurringEvent n’a pas. Plutôt que d’étendre ma solution pour travailler avec n’importe quelle classe du monde, j’ai profité du DataItem propriété que RecurringEvent hérite de la télérik Appointment classe.

Le DataItem la propriété est déclarée comme un objet de type donc DataItem maintiendra n’importe quel objet .NET (n’importe quoi d’une chaîne à une collection). J’ai juste besoin de configurer mon code afin que tout ce qui se trouve dans un objet de planification DataItem la propriété est transmise à tous les objets connexes qui SchedulerManager crée.

Maintenant, quand j’utilise RecurringEvent Dans une autre application, je peux stocker toutes les informations supplémentaires dont la demande a besoin dans le DataItem propriété, confiant que SchedulerManager propagera cette propriété de manière appropriée.

Et voici le code pour le Classe RecurringEvent.

Planificateur

Ayant défini le seul objet avec lequel mon code doit fonctionner, l’étape suivante consiste à écrire le code qui utilise cet objet – initialement en ne prenant en charge les cas typiques.

Ainsi, par exemple, mon SchedulerManager Expose les trois méthodes requises pour prendre en charge les parties de la fonctionnalité du planificateur qui m’intéresse: l’ajout, la mise à jour et la suppression des événements planifiés (j’ai couvert ces méthodes dans ma série précédente). Maintenant, pour le cas typique, je peux simplement câbler ces méthodes à Scheduler OnCreate, OnUpdate et OnDelete Méthodes comme je l’ai montré au début de ce post (reconnaissant que si je câbler les deux OnCreate et OnUpdatel’interface utilisateur du blazor peut lancer une exception lorsque l’utilisateur double-cliquez sur un événement planifié et le modifie).

Si vous êtes intéressé, voici le code pour Planificateur et Planificateur.

Position de la personnalisation

Une fois que vous êtes configuré pour prendre en charge les cas typiques, vous pouvez envisager d’étendre vos objets réutilisables pour prendre en charge un ensemble minimal de personnalisations attendues. Ou pas – la prise en charge du cas typique est un endroit parfaitement bon pour s’arrêter et passer à l’application suivante. Cela dit, certaines personnalisations sont plus faciles à supporter que d’autres.

Par exemple, des objets réutilisables complets comme SchedulerManager Je fera parfois trop pour vous – il y aura des cas où vous préféreriez exercer plus de contrôle que l’objet réutilisable.

Pour soutenir cette affaire, j’ai séparé mon code en deux classes: tandis que SchedulerManager prend en charge toutes les fonctionnalités que je veux dans Scheduler, il le fait en appelant des méthodes dans une autre classe appelée SchedulerDataManager. SchedulerDataManager fournit uniquement l’ensemble minimal de fonctionnalités pour gérer la liste des événements de Scheduler. Donc, si je trouve ça SchedulerManager fait trop, je peux ignorer SchedulerManager et construire mon application en utilisant SchedulerDataManager.

Le scénario de personnalisation alternatif est lorsque votre objet réutilisable n’en fait pas assez. Vous pouvez prendre en charge cette affaire en ayant vos événements d’objet réutilisables à des moments critiques de son traitement – qui vous permet d’ajouter du code supplémentaire au traitement par défaut de l’objet réutilisable si nécessaire. Par exemple, j’ai configuré SchedulerManager Pour tirer des événements chaque fois qu’un objet d’événement est ajouté, mis à jour ou supprimé (et a intelligemment appelé ces événements OnEventAdded, On EventUpdated et OnEventDeleted).

À titre d’exemple du moment où ces événements peuvent être utiles, SchedulerManagerLe traitement par défaut suppose que je vais mettre à jour ma base de données après la fin de l’utilisateur en interaction avec mon application et clique sur un bouton Enregistrer. Par exemple, SchedulerManager stocke l’événement objet qu’il supprime dans un DeletedItems Liste que je peux utiliser pour supprimer les données de ma base de données lorsque l’utilisateur clique sur le bouton Enregistrer mon application.

Personnellement, j’aime une «stratégie de bouton Enregistrer» car elle prend également en charge un bouton d’annulation qui permet à l’utilisateur d’expérimenter son horaire sans avoir à l’enregistrer.

Cependant, il pourrait y avoir un cas où je dois mettre à jour ma base de données en tant que mon utilisateur apporte des modifications (Une application où les modifications doivent être vues en temps réel, par exemple). Si ce cas apparaît, je pouvais (vraisemblablement) gérer cela en insérant le code de mise à jour de la base de données personnalisé dans les événements de ScheduerManager pour étendre le traitement par défaut de SchedulerManager.

De plus, les trois événements sont passés un paramètre d’événement qui comprend un Cancel Propriété qui, lorsqu’elle est définie sur True, empêche SchedulerManager de faire son traitement «normal». Cela me permet non seulement d’étendre le traitement de SchedulerManager, mais aussi de le remplacer: j’ajoute du code dans un événement, puis de définir le Cancel propriété à vrai pour empêcher le traitement normal de ScheduerManager de se produire.

Ne pas prendre en charge la personnalisation

Vous devrez décider du niveau de personnalisation que vous êtes prêt à soutenir (en vous rappelant que «aucun» est une option parfaitement bonne). Il y a aussi un terrain d’entente ouvert: structurez votre objet pour prendre en charge une personnalisation potentielle, mais différez la rédaction du code requis quand (et si) vous en avez réellement besoin.

Par exemple, comme je l’ai discuté dans le dernière partie de ma série sur le support de support, permettant à l’utilisateur d’ajouter plusieurs horaires peut créer un problème. C’est un cas de niche, cependant, et ne se produit que si vous permettez à l’utilisateur d’ajouter à la fois de nouveaux événements et plusieurs horaires au planificateur. Par défaut, ScheduleManager évite ce problème en empêchant l’utilisateur d’ajouter plusieurs horaires.

Mais, plutôt que de couper complètement l’option de plusieurs horaires, j’ai ajouté une propriété appelée SupportMultipleSchedules à SchedulerManager. Lorsque la propriété est définie sur TRUE, ScheduleManager permet à l’utilisateur d’ajouter plusieurs horaires. Tout était facile à faire car tout ce que j’ai fait était d’inclure un bloc de code vide où je serais, un jour et si j’en ai besoin, écrivez le code le plus difficile qui gère plusieurs horaires. Si jamais je crée réellement une application qui a besoin de plusieurs horaires, je remplirai alors ce bloc de code vide.

Un autre exemple: Bien que les différents événements qui sont licenciés par SchedulerManager puissent être annulés, ils n’empêchent pas l’utilisateur de supprimer une occurrence régulièrement planifiée (le planificateur les gère à peu près en interne, ce qui rend difficile l’interférer avec le processus). Je n’ai même pas essayé de soutenir cela. Si jamais j’écris une application où je dois empêcher un utilisateur de supprimer une occurrence à partir de ScheduleManager, je vais trouver un moyen de le faire alors… et je reconnais que cela peut ne pas impliquer du code à SchedulerManager.

Ignorer un problème n’est pas une solution viable pour un produit commercial. Cependant, je m’en fiche car mon travail consiste à fournir des demandes à mon client, pas aux objets commerciaux. Je ne suis intéressé que par la réutilisabilité dans la mesure où cela me permet (et la boutique informatique de mon client) de livrer des applications ultérieures plus rapidement. Et, autant que j’aime augmenter mes heures facturables, résoudre des problèmes ni moi ni mon client ne faisons actuellement partie de ma description de travail. Cela ne fait pas non plus partie de la vôtre.

Plongez dans ce domaine vous-même: essayez une interface utilisateur Telerik gratuitement pendant 30 jours.

Essayer maintenant