Cours d’intégration d’applications

Suivez une intégration sur le serveur et le navigateur. Wisej.NET possède l'état du composant, tandis qu'un widget de navigateur le présente. Garder cette limite explicite empêche la bibliothèque du fournisseur de devenir la couche métier de l’application.

Distinguez le composant de son widget. Le composant possède l'état de l'application ; le widget gère le comportement du navigateur. Les événements les connectent en signalant des changements significatifs, plutôt que de copier chaque interaction du navigateur sur le serveur.

Suivez les données vers l'extérieur sous la forme compacte JSON, puis dans les options du fournisseur. Retracez les événements importants jusqu'au serveur. Cette limite d'adaptateur permet au code du serveur de fonctionner avec un contrat stable au lieu de détails spécifiques au fournisseur.

Inspectez TemperatureGauge dans le concepteur. Value est la propriété modifiée par l'application ; ThresholdExceeded est l’événement qu’il gère. La jauge du fournisseur reste à l’intérieur de cette interface de composant Wisej.NET familière.

Regardez le serveur changer Value et la jauge le restitue. Au seuil affiché, un événement revient avec des informations utiles. L'application répond au franchissement du seuil, pas à chaque image d'animation visuelle.

Classez la jauge, l'éditeur et la grille avant d'écrire le code d'intégration. Leurs besoins en ressources, données et événements diffèrent. Comparer ces besoins permet d’abord de choisir une surface d’intégration suffisante sans complexité inutile.

Rédigez un dossier de décision d'architecture expliquant votre choix. Incluez les contraintes de réutilisation, de thème, de sécurité et de maintenance. Le but est de conserver le raisonnement, afin qu'un autre développeur puisse juger plus tard si le choix est toujours pertinent.

Soumettez le diagramme, le tableau de comparaison et le dossier de décision ensemble. Ils doivent raconter une histoire cohérente : où vit l'État, comment le widget communique et pourquoi l'approche d'intégration sélectionnée correspond à ses exigences.

Vous disposez désormais d’une conception d’intégration que quelqu’un d’autre peut réviser. Utilisez cette compréhension partagée comme point de départ pour la mise en œuvre et les tests, au lieu de traiter un visuel fonctionnel comme l’intégralité de l’intégration.

Prouvez le comportement de JavaScript avant de l'envelopper dans Wisej.NET. Un petit exemple isolé permet de distinguer une erreur de bibliothèque ou de langage d'un problème introduit par l'intégration elle-même.

Dans le rappel du fournisseur, inspectez à quoi fait référence this. Il peut s'agir de l'objet fournisseur, qui n'a pas de méthode fireWidgetEvent. La méthode manque parce que le récepteur est erroné, et non parce que Wisej.NET a perdu l'événement.

Conservez une référence explicite au widget dans une fermeture, liez le rappel ou appelez une méthode de widget. Chaque solution donne au rappel un itinéraire fiable vers la bonne instance lorsque le fournisseur l'invoque.

Déclarez les dépendances dans l'ordre requis : bibliothèque de prise en charge, styles, script du fournisseur, puis initialisation. Packages rend cet ordre explicite, empêchant l'initialisation de s'exécuter avant que les ressources requises n'existent.

Déplacez l'initialisation éprouvée dans le InitScript du Widget et déclarez ses ressources dans Packages. Conservez les mêmes hypothèses de dépendance que celles de l'exemple isolé, afin que l'intégration ne modifie pas silencieusement la façon dont la bibliothèque démarre.

Utilisez les outils de développement du navigateur pour inspecter l'instance de fournisseur stockée et suivez valueChanged. Un sourceURL donne au code injecté un nom reconnaissable ; une instruction du débogueur permet d'arrêter l'endroit où le rappel s'exécute réellement.

Conservez l'exemple isolé, le travail InitScript et les notes de débogage ensemble. Un échec futur peut alors être reproduit en dehors de l’intégration et comparé à la configuration réelle du widget.

L'intégration dispose désormais d'un point de départ testé, de dépendances explicites et d'un contexte de rappel fiable. Ces fondations facilitent le débogage du code wrapper ultérieur, car le comportement de base de JavaScript est déjà compris.

Commencez avec un Widget pour prouver rapidement l’intégration. Cela donne à la bibliothèque du fournisseur une place dans Wisej.NET avant d'investir dans un contrôle réutilisable avec une interface publique plus grande.

Placez le Widget sur le tableau de bord et gardez le premier exemple petit. La question immédiate est de savoir si les ressources se chargent et si l'objet fournisseur peut s'exécuter dans son conteneur, et non si l'abstraction est terminée.

Donnez des tâches distinctes à Packages, Options et InitScript. Packages charge les dépendances, Options transporte les données actuelles et InitScript crée le visuel. Garder ces rôles clairs facilite le diagnostic d’un échec d’intégration.

Créez l'instance du fournisseur lors de l'initialisation, puis mettez à jour cette instance existante lorsque les options changent. Le recréer à chaque mise à jour peut dupliquer les gestionnaires ou perdre l'état qui appartient au widget actuel.

Utilisez le bouton du serveur pour modifier Options et regarder la mise à jour actualiser le visuel. Un appel en file d'attente gère une commande impérative. Faites la distinction entre la modification de l’état persistant du widget et la demande d’une action client unique.

Soumettez ensemble les déclarations de ressources, l’initialisation, la logique de mise à jour et l’interaction du serveur. Ils doivent démontrer à la fois la première création et les modifications ultérieures. La réutilisation sur plusieurs écrans est la prochaine raison d'introduire un wrapper.

Le prototype a maintenant établi que la bibliothèque peut charger, restituer et répondre dans Wisej.NET. Transférez ces comportements éprouvés dans un emballage réutilisable au lieu de copier le prototype sur chaque page.

Déplacez la configuration répétée du widget dans une classe réutilisable. Lorsque les chemins de ressources ou l'initialisation changent, une implémentation maintenue doit servir chaque écran au lieu de nécessiter des modifications sur plusieurs scripts copiés.

Laissez SimpleGauge hériter du comportement Wisej.NET Widget et posséder ses Packages, Options et InitScript. La page doit demander le comportement de la jauge à travers la classe, sans savoir comment la bibliothèque du fournisseur est assemblée.

Exposez Value, Minimum, Maximum et Caption en tant que propriétés saisies. Les descriptions et les catégories aident l'utilisateur concepteur à choisir des paramètres valides, tandis que le wrapper traduit ces paramètres en options du fournisseur en interne.

Gardez les propriétés prises en charge publiques et masquez les détails d’implémentation le cas échéant. Si les appelants peuvent remplacer librement les options d’initialisation ou brutes, ils peuvent contourner les garanties qui rendent le wrapper fiable.

Placez la classe sur une page de démonstration et modifiez-la via les propriétés normales. L'absence de InitScript spécifique à la page est une preuve utile : les connaissances d'intégration vivent réellement à l'intérieur de la classe réutilisable.

Fournissez la classe avec des propriétés documentées, des valeurs par défaut et une page d'exemple propre. Un réviseur doit être capable de l'instancier et de comprendre les paramètres pris en charge sans ouvrir le script d'initialisation du fournisseur.

Un bon emballage rend le fonctionnement normal simple et rend difficile une mauvaise utilisation accidentelle. Évaluez l’interface publique du point de vue de l’auteur de la page, et pas seulement du point de vue de la personne qui a construit l’intégration.

Créez un contrôle personnalisé lorsque l'intégration doit se comporter comme une partie de Wisej.NET elle-même. L'objectif est un composant réutilisable qui participe au comportement et à la thématique au moment de la conception, et pas seulement un visuel hébergé.

Comparez un wrapper Widget avec un Control au niveau de la plate-forme. Choisir l'intégration la plus forte lorsque le comportement natif et la participation thématique le justifient ; un travail de mise en œuvre supplémentaire devrait répondre à une réelle exigence de réutilisation.

Associez le serveur SimpleGaugeControl à sa classe client sous Platform. Les deux classes ont des responsabilités différentes : le serveur expose l'état de l'application, tandis que le client implémente la manière dont cet état apparaît et se comporte dans le navigateur.

Utilisez OnWebRender pour créer une configuration client délibérée. Incluez les propriétés nécessaires au rendu de la jauge, plutôt que de sérialiser des objets serveur sans rapport. Une petite limite explicite est plus facile à raisonner et à maintenir.

Connectez la clé d'apparence à la définition du thème. Cela permet au thème de contrôler les choix visuels au lieu de coder en dur un aspect distinct dans chaque écran qui utilise le contrôle.

Inspectez le contrôle dans le concepteur et essayez ses paramètres de taille et de thème. Le rendu au moment de la conception fait partie de l'intégration : les autres développeurs doivent organiser le contrôle sans exécuter au préalable l'intégralité de l'application.

Soumettez les deux classes, l’entrée d’apparence et les preuves au moment de la conception. Ensemble, ils démontrent le chemin complet depuis la propriété du serveur jusqu'à un contrôle thématique qu'un autre développeur peut placer visuellement.

Regardez plusieurs instances partager la même implémentation de contrôle sur le tableau de bord. Leurs valeurs varient, mais leur comportement et leur intégration thématique restent cohérents. Cette cohérence est la récompense de l’encapsulation de l’intégration une fois.

Déterminez si chaque interaction envoie une commande ou doit obtenir un résultat. Cette distinction détermine comment le code serveur poursuit son exécution, quelles données franchissent la frontière et s’il doit attendre une réponse du navigateur.

Utilisez Call lorsque le navigateur doit effectuer une action et qu’aucune valeur de retour n’est nécessaire. La commande est mise en file d'attente, le code serveur ultérieur ne doit donc pas supposer que le navigateur a déjà fini de l'exécuter.

Utilisez CallAsync ou EvalAsync lorsque l'étape suivante dépend du résultat du navigateur. Attendez l'opération avant d'utiliser ce résultat, afin que le flux de travail suive la réponse au lieu de se précipiter avec les données manquantes.

Définissez un petit objet de transfert de données et vérifiez ses noms de propriétés sérialisés. Le navigateur reçoit le contrat sérialisé, pas l'objet C# d'origine. Les champs explicites évitent d’exposer des états non liés et réduisent les incompatibilités de noms.

Comparez les opérations en direct : une commande modifie la jauge, un appel dont on attend le résultat lit sa taille après rendu, et un objet compact renvoie l’état de la sélection. Chaque échange transporte uniquement les données nécessaires à cette interaction.

Fournissez des exemples de commandes sans retour et d’appels dont on attend le résultat, ainsi que le contrat des données renvoyées. Une personne qui examine le code doit pouvoir identifier où l’exécution attend et quels champs le navigateur est autorisé à renvoyer.

Gardez la frontière organisée autour des commandes, des résultats et des contrats de données explicites. Cela rend visibles le timing et la responsabilité, ce qui est plus fiable que de traiter le code du navigateur comme une extension synchrone du serveur.

Traitez les rappels des fournisseurs comme une entrée brute de l'intégration. L'application a besoin d'un ensemble stable d'événements significatifs, l'adaptateur doit donc décider quoi transférer plutôt que d'exposer directement chaque notification du fournisseur.

Séparez l’activité visuelle des décisions d’application. Le mouvement ou l'animation du pointeur peut rester local, tandis qu'une sélection significative ou un changement d'état peut nécessiter le serveur. Le filtrage à cette limite évite le trafic inutile et le travail des gestionnaires.

Enregistrez le rappel du fournisseur une fois lors de l'initialisation et transférez un événement nommé compact. L'enregistrer à nouveau à chaque mise à jour peut faire en sorte qu'une action utilisateur déclenche plusieurs gestionnaires de serveur de manière inattendue.

Utilisez la route des événements qui correspond à la surface d'intégration. Widgets transmis via fireWidgetEvent et WidgetEvent ; les contrôles personnalisés utilisent leurs événements client et OnWebEvent. Le mélange des routes envoie les données au mauvais mécanisme de traitement.

Définissez le nom de chaque événement et la charge utile avant de câbler les gestionnaires. Les franchissements de seuils, les changements de valeurs et les sélections de points nécessitent des informations différentes. Les petits contrats explicites indiquent clairement sur quoi un gestionnaire de serveur peut s'appuyer.

Interagissez avec la jauge, le bouton et le graphique et suivez les événements atteignant le serveur. Vérifiez que chaque charge utile contient les valeurs pertinentes et que l'activité visuelle locale n'est pas devenue un flux de messages serveur inutiles.

Soumettez les gestionnaires client et serveur appariés avec la table de contrat. Un réviseur doit être capable de retracer chaque événement depuis le déclencheur de son navigateur jusqu'à la décision du serveur, y compris exactement quelles données franchissent la frontière.

Certains widgets de fournisseurs récupèrent leurs propres données plutôt que de tout recevoir via Options. Donnez à ces requêtes un point de terminaison explicite et conservez le contexte de composant correct, afin que la réponse appartienne à l'utilisateur et au widget prévus.

Utilisez getPostbackUrl lorsqu'un widget attend une adresse de données. Il achemine la demande vers la session et l'instance de composant appropriées. L'adresse fournit le contexte, mais le gestionnaire doit quand même valider l'opération demandée.

Dans WebRequest, vérifiez l'action demandée avant de produire des données. Définissez le type de contenu JSON et écrivez la forme de réponse attendue. Une réponse de transport valide ne suffit pas si le widget ne peut pas interpréter son contenu.

Utilisez un WebMethod pour une opération typée que votre code client appelle directement. Les arguments et la valeur renvoyée forment le contrat, de sorte que l'appelant peut attendre un résultat au lieu de gérer une demande de données appartenant au widget.

Choisissez le style de point de terminaison en fonction de la personne qui initie et contrôle la demande. Une source de données fournisseur utilise naturellement son adresse ; le code d'application qui appelle une opération nommée bénéficie d'une méthode typée et d'un résultat explicite.

Suivez la demande de la grille au gestionnaire de publication et revenez aux lignes rendues. Vérifiez la structure de réponse à cette limite ; une grille vierge peut indiquer une inadéquation de contrat même lorsque la demande elle-même a abouti.

Fournissez les deux exemples de points de terminaison et expliquez leurs appelants prévus. Vérifiez l’autorisation et la validation des entrées pour chaque chemin. Le choix d’un mécanisme de point de terminaison pratique ne supprime jamais la responsabilité du serveur de protéger l’opération.

Utilisez les exemples de grille et de pivot pour identifier le modèle d'intégration sous la syntaxe spécifique au fournisseur. L'application a toujours besoin de chargement de ressources, d'opérations de données, d'événements et d'une interface Wisej.NET stable quelle que soit la bibliothèque choisie.

Donnez à l'adaptateur la propriété de la création, des options, des événements et de l'accès aux données. Le fait de conserver ensemble ces informations destinées aux fournisseurs empêche les pages individuelles de développer leurs propres versions incompatibles de la même intégration.

Comparez DataSource et CustomStore en fonction des opérations qu'ils demandent, et pas seulement de leur syntaxe. Les deux ont besoin d’un chemin pour charger et modifier les données ; l'adaptateur traduit leurs arguments dans le contrat de votre serveur.

Définissez la pagination, le tri et le filtrage dans GridOperationRequest avant d'implémenter les gestionnaires. Validez ces entrées sur le serveur, puis mappez-les à l'opération prise en charge. Les instructions de requête fournies par le navigateur ne sont toujours pas des entrées fiables.

Spécifiez des charges utiles distinctes pour les événements de modification de ligne, d’insertion, de suppression et de sélection. Chacun doit identifier l’opération prévue et les valeurs nécessaires, sans envoyer un composant entier ni exposer l’état du serveur sans rapport.

Suivez la pagination, le tri et l'édition via le même contrat de serveur pendant que le pivot charge ses données. La limite commune maintient les opérations des applications compréhensibles même lorsque les widgets du navigateur utilisent des interfaces de fournisseurs différents.

Soumettez le contrat d'exploitation, les gestionnaires, les charges utiles d'événement et le plan pivot comme une seule conception cohérente. Un réviseur doit être capable de connecter chaque action de données visible à une opération de serveur explicite et validée.

Considérez l’intégration comme quelque chose qui doit survivre à une utilisation et un déploiement répétés. Un premier rendu réussi ne prouve qu'un seul chemin ; la préparation à la production dépend également de la gestion des pannes, des mises à jour, du nettoyage et des contrats maintenables.

Inspectez les chemins de ressources, le volume des événements, le nettoyage du cycle de vie, la synchronisation et les tailles de données réalistes. Ces soucis peuvent rester cachés dans une petite démonstration, puis se transformer en échecs lorsque le même widget est réutilisé ou déployé ailleurs.

Name a injecté des scripts avec sourceURL et échoue clairement lorsque les conditions préalables sont manquantes. Comparez l'exemple du fournisseur isolé avec la version intégrée. Cela vous donne des preuves de l’endroit où commence l’échec au lieu de vous fier à des conjectures.

Mettez à jour l’instance de fournisseur existante et détruisez-la lorsque le contrôle est supprimé. Les cycles répétés de création et de fermeture ne doivent pas laisser les gestionnaires ou les objets en vie après la disparition de leur écran.

Démarrez le traitement en arrière-plan via Application.StartTask. Lorsque le résultat est prêt, mettez à jour le client et appelez Application.Update. Le flux de travail n’est pas terminé tant que le navigateur n’est pas en mesure d’afficher le nouvel état du serveur.

Intégrez un widget inconnu en utilisant les mêmes limites : un wrapper réutilisable, des commandes de serveur, un événement significatif et un point de terminaison de données protégé. L’exercice teste si vous pouvez transférer le modèle au-delà des exemples du cours.

Examinez le tableau de bord comme plusieurs intégrations travaillant ensemble. Suivez les événements, les appels, le chargement et l'élimination pour chaque widget. L'espace visuel partagé ne doit pas brouiller le wrapper qui possède chaque ressource et interaction.

Terminez avec un wrapper qu'un autre développeur peut comprendre, tester et réutiliser. Expliquez son contrat public et son cycle de vie, y compris le comportement en cas d'échec. Le résultat durable est une intégration maintenable, pas seulement une démonstration impressionnante.