Plonger dans les derniers avantages du concepteur de rapports basé sur le Web

Obtenez un aperçu des parties les plus stimulantes et les plus intéressantes de la dernière croissance de Web Report Designer.

Modifications architecturales intéressantes sous le capot, prise en charge des objets métier et améliorations de la qualité de vie dans le Telerik Web Report Concepteur.

Dans cet article de blog, nous examinons de près les dernières fonctionnalités du concepteur qui amélioreront votre expérience globale lorsque vous travaillez avec. Restez à l'écoute pour en savoir plus.

Éditeurs de propriétés

Le problème

Les éditeurs de propriétés sont l'une des principales parties de la base de code des concepteurs de rapports basés sur le Web. Nous avons de nombreux types de propriétés différents, avec leur propre logique spécifique, à la fois pour les données qu'elles représentent et pour la manière dont elles doivent être affichées et communiquer avec l'aire de conception. Elles regorgent d'action.

Faire cela avec jQuery et Kendo UI nous ont présenté pas mal de défis. Pour commencer, nous avons conservé les modèles HTML dans les fichiers TypeScript – ce n'est pas un problème majeur pour les petits morceaux de HTML, mais cela s'est avéré être un problème avec les modèles plus gros et plus complexes. Combiné avec le fait que la manipulation du DOM se faisait principalement via jQuery et que la mise à jour des modèles TypeScript se faisait via des événements, la lecture et le traçage de la logique du code étaient devenus un défi.

La gestion des états s'avérait également être un problème. – nous utilisions des événements personnalisés pour tout, encore une fois, cela ne nous aidait pas à garder les choses simples. La complexité avait atteint un niveau record.

Premiers pas

Nous avons décidé qu'il était temps de changer. L'un des moyens les plus efficaces de réduire l'encombrement était de déplacer les modèles HTML vers leurs propres fichiers. Mais cela semble plus simple qu'il ne l'est : nous avons un grand nombre de modèles et nous ne voulions pas les charger à partir du serveur, car cela aurait eu un effet notable sur les performances. De plus, cela aurait nécessité de les stocker en tant que ressources, ce qui compliquerait davantage les choses. et la mise à jour des balises et tous les autres avantages fournis par les IDE.

C'est ainsi que nous avons créé notre générateur de modèles HTML vers TypeScript simple mais efficace. Son travail consiste à surveiller les modifications du fichier HTML (ajouter, supprimer et modifier) ​​et à générer un fichier TypeScript, qui a un objet qui contient les modèles du système de fichiers. La structure de l'objet ressemble à la structure du dossier. Par exemple, si nous avons cette structure de fichiers/dossiers :

CatsAndDogs
    chatsEtChiens.html
    Chat
        chat.html
    Chien
        chien.html

Le fichier de modèles résultant sera :

export const Modèles = {
    ChatsEtChiens : {
        chatsEtChiens : `...`,
        Chat : {
            chat : `...`
        },
        Chien : {
            chien : `...`
        }
    }
}

De cette façon, nous pourrions commencer à déplacer le code HTML des fichiers TypeScript avec une relative facilité et sans considération de performances. Nous avons commencé à exécuter notre plan, puis nous avons remarqué quelque chose…

Data-binding, Kendo UI, MVVM et plus

Après avoir déplacé certains modèles, nous avons remarqué que nous pourrions bénéficier de l'utilisation de l'interface utilisateur de Kendo MVVM pour simplifier la façon dont nous avons travaillé avec le DOM. Déplacer des parties de la logique de l'éditeur de propriétés vers Observable Objectspuis utiliser une View pour connecter le HTML et JavaScript était notre plan initial, mais cela impliquait à nouveau un travail manuel et répétitif et quelques questions — quand la liaison doit-elle se produire, que se passe-t-il si nous voulons exécuter quelque chose avant/après la phase de liaison, quand la dissociation doit-elle se produire car les gestionnaires d'événements sont également impliqués. commencé à utiliser des Observables fortement typés pour la gestion de l'état et la communication, mais encore une fois, nous n'avions pas de façon claire et établie de faire les choses. , ajoutez des hooks de cycle de vie (avant/après init/destroy) et disposez d'une manière uniforme d'utiliser le modèle MVVM.

Nous les avons appelés composants. Maintenant, si vous venez du monde Angular/React/Vue, vous connaissez l'idée des composants, mais, si ce n'est pas le cas, voici un petit récapitulatif des principaux objectifs d'un composant :

• Contient des données d'application et est associé à un modèle HTML, qui définit une vue qui sera affichée dans la page Web
• Indépendant et réutilisable
• Encapsule son code HTML et JavaScript
• Peut contenir des composants enfants dans sa vue et peut communiquer avec eux via liaisons

Nous avons facilement accompli les trois premiers points, mais le défi est venu de prendre en charge les composants enfants et les liaisons. Nous voulions pouvoir utiliser un nom d'élément HTML pour le composant dans nos vues et créer des liaisons de manière déclarative :

<cat name= ”Nom” onCatMoving=”catMoving”></cat>

Mais nous ne voulions pas non plus affecter les performances.

La solution est assez élégante : nous utilisons des décorateurs TypeScript pour enregistrer des composants dans un gestionnaire global, et pour trouver des composants enfants, nous utilisons un attribut, data- wrd-component :

<cat data-wrd-component name="Name"  ="chat en mouvement"></chat>

Après avoir rendu le composant (Kendo View), nous recherchons tous les éléments marqués par "data-wrd-component", effectuons une recherche dans le registre pour leur nom synthétique, créons une instance de la classe de composant et insérons le résultat du rendu dans l'élément synthétique :

<cat data-wrd-component name="Name" onCatMoving[196590] ="catMoving">
    <img src="cat.png">
</cat[24659] ]>

D'accord, cela couvre le rendu des composants enfants, mais qu'en est-il des liaisons ? Nous avions besoin de liaisons d'entrée (parent-enfant) et de sortie (enfant-parent).

Nous avons de nouveau utilisé des décorateurs pour marquer les champs/propriétés comme entrées/sorties. Pour les liaisons d'entrée, Kendo UI nous a couverts. Comme les composants sont des objets observables, nous pouvons nous lier à l'événement "modifier" et mettre à jour la propriété requise dans le composant enfant.

Pour les liaisons de sortie, nous avons utilisé un émetteur d'événement. Le "onCatMoving" de l'exemple ci-dessus est un émetteur d'événements dans le composant enfant, tandis que le "catMoving" est une fonction dans le composant parent. Nous connectons automatiquement les choses et le composant enfant doit uniquement appeler la méthode d'émission de l'émetteur d'événements pour mettre à jour le parent. CreationStrategy" data-displaymode="Original" data-openoriginalimageonclick="true"/>

Nous avons finalement pu commencer à utiliser les composants dans les éditeurs de propriétés. Après un peu de refactorisation, les éditeurs de propriétés ont évolué pour être plus petit, plus simple et plus efficace. Nous avons divisé certains éditeurs en plusieurs composants, commencé à nous appuyer sur les liaisons de composants pour transmettre les données requises et utilisé la liaison de données prête à l'emploi de l'interface utilisateur de Kendo pour travailler avec le DOM.

Utilisation tout cela, nous avons pu améliorer un peu nos tests, tout en facilitant l'écriture de nouveaux. Nous avons également pu résoudre de nombreux problèmes dans les éditeurs existants, sans nous soucier des effets secondaires involontaires, et améliorer la vitesse de la création et de la qualité des nouveaux edi teurs.

Voyant que l'utilisation de l'approche des composants fonctionne pour nous, nous avons commencé à l'utiliser pour toutes les choses applicables dans le concepteur de rapports Web.

Source de données d'objets

La source de données d'objets nous donne la possibilité d'utiliser des des objets de classe à partir d'un assembly personnalisé en tant que source de données. Mais comment cela se fait-il dans le contexte d'une application Web ? Aussi, comment les risques de sécurité sont-ils annulés ? Ce sont toutes de bonnes questions auxquelles nous allons répondre.

Tout d'abord, nous devons charger les assemblys sur le serveur, sur lequel le service Web Report Designer est exécuté. Ensuite, nous devons obtenir les informations sur les types qui s'y trouvent, afin de pouvoir envoyer ces informations à l'interface. Mais quels assemblages utiliser ? L'utilisation de tous les assemblys disponibles est un risque de sécurité sérieux, car cela donnerait aux utilisateurs la possibilité d'exécuter tout ce qu'ils veulent ou, pour le dire autrement, l'exécution de code à distance. Pour éviter cela, nous utilisons l'élément de références d'assemblyqui donne aux développeurs la possibilité d'inclure uniquement les assemblys qu'ils souhaitent rendre disponibles.

Mais parfois, les assemblys ont hérité des noms d'assembly, ce que nous ne souhaitons peut-être pas. inclure. Pour cette raison, nous avons les éléments clear et removequi peuvent respectivement supprimer tous les noms hérités ou en supprimer un en particulier.

D'accord, après avoir surmonté ce problème, nous pouvons continuer à collecter nos données. Nous chargeons les assemblages qui se trouvent dans l'élément de référence d'assemblage et, à l'aide de la réflexion, nous obtenons les types qui s'y trouvent. Nous recueillons des informations de base à leur sujet, comme l'espace de noms et le nom, et les sérialisons en JSON. Ces informations sont ensuite affichées dans la première page de l'assistant de source de données d'objet.

Pour la deuxième page, où nous sélectionnons le membre de données, nous renvoyons le type choisi au serveur et à nouveau avec l'aide de la réflexion, nous collectons la propriété/ informations de méthode/constructeur pour le type donné, sérialisez-les en JSON et envoyez-les à l'interface.

Il est important de mentionner que la validation est exécutée à chaque étape de la configuration, afin que nous ne donnions accès à rien d'extérieur des assemblys enregistrés.

Si le membre de données choisi a des paramètres, nous afficherons une page de configuration des paramètres dans l'assistant, où les valeurs réelles et au moment de la conception des paramètres peuvent être définies.

Ayant tout configuré, nous peut envoyer les informations de la source de données au serveur, où nous chargeons les assemblys et les types, et obtenons les informations pour le membre de données, afin que nous puissions afficher un aperçu des résultats. Et c'est tout : la source de données d'objet est prête à être utilisée dans votre rapport !

Pour plus d'informations sur la configuration, vous pouvez consulter la page ObjectDataSource Wizard. Par exemple, vous pouvez ouvrir le rapport de démonstration des intervenants, qui utilise une bibliothèque d'objets métier préconfigurés (disponible à partir de R3 2021 SP1).

Ajout de la prise en charge du style Copier/Coller/Réinitialiser—Ou comment le modèle de commande nous facilite la vie[19659084]L'ajout de la prise en charge de quelque chose comme copier ou coller peut devenir compliqué, selon ce qui doit être copié et d'où les données copiées doivent être accessibles.

La prise en charge de la modification de style en est un bon exemple. Les informations de style doivent être copiées depuis un composant, une zone de texte par exemple, puis coller doit être disponible à la fois depuis le menu contextuel et depuis un raccourci pour tous les autres composants qui ont des styles. De plus, le collage doit être pris en charge pour plusieurs composants.

Notre solution consiste à utiliser le modèle de commande et à disposer de toute la logique associée à la façon dont un style doit être copié/collé, quels composants ont été ciblés et ce qui doit être actualisé encapsulé dans une commande. La commande s'occupe de tout, sait si elle est disponible pour l'exécution (par exemple, les commandes de style copier/coller/réinitialiser ne peuvent pas être exécutées sur les sources de données, et les commandes en sont conscientes !), et de cette façon la seule responsabilité du l'utilisateur de la commande doit l'appeler (également, dans certains cas, vérifier si un élément de l'interface utilisateur doit être affiché en interrogeant la disponibilité de la commande).

En utilisant la même approche, nous avons implémenté une grande partie de nos interactions d'interface utilisateur, y compris actions de menu, création et sélection de composants, en gardant tout bien organisé et facile pour une utilisation future. et nous en sommes ravis !

Dans cet article, nous avons plongé la tête la première dans les parties les plus stimulantes et les plus intéressantes de la dernière évolution de Web Report Designer. J'espère que vous avez apprécié la lecture de l'article et que j'ai pu vous donner un aperçu du fonctionnement interne de notre concepteur Web. Si vous êtes intéressé par quelque chose de particulier ou si je ne peux pas expliquer certains concepts assez bien ou avec suffisamment de détails, veuillez ajouter une ligne dans les commentaires. Je vous en serais très reconnaissant.

Telerik Reporting est un outil de création de rapports intégré .NET complet, facile à utiliser et puissant pour les applications Web et de bureau qui prend en charge : Blazor, ASP.NET Core, ASP.NET MVC, ASP.NET AJAX, HTML5/JS, angulaire, WPF, WinForms et UWP. Également disponible dans le cadre de notre offre Telerik DevCraftReporting vous permet de créer, styliser, afficher et exporter des rapports riches, interactifs et réutilisables pour présenter de manière attrayante des données analytiques et des données commerciales. Ajoutez des rapports à n'importe quelle application métier via les contrôles de la visionneuse de rapports. Exportez les rapports prêts dans plus de 15 formats.

Si vous ne l'avez toujours pas essayé, vous pouvez démarrer un essai gratuit pour regarder de plus près. Nous fournissons également un service d'assistance dont nous sommes fiers et des ressources qui vous aideront tout au long du processus.