Fondamentaux

Module un. Votre première application Wisej.NET. Nous allons créer un petit écran qui demande un nom et affiche un message d'accueil. Ceci présente le flux de travail de base : concevoir l'interface, gérer un événement et tester le résultat dans un navigateur.

Commencez dans Visual Studio et choisissez Créer un nouveau projet. Wisej.NET utilise le flux de travail de projet familier, avec des modèles qui fournissent les fichiers d'application initiaux. L'interface s'exécutera dans le navigateur, tandis que notre code d'événement s'exécutera sur le serveur.

Recherchez Wisej.NET. Cette procédure pas à pas utilise le modèle d'application Web Wisej.NET 4 avec C#. Sélectionnez ce modèle et continuez. S'il est absent de votre propre installation, vérifiez que l'extension Wisej.NET et les modèles de projet sont installés avant de continuer.

Choisissez un nom de projet et un emplacement, puis cliquez sur Créer. Visual Studio génère le projet et sa fenêtre de démarrage. Regardez Solution Explorer : c'est ici que vous trouverez les fichiers de l'application et reviendrez à la fenêtre au fur et à mesure que vous construisez l'écran.

Construisez le projet avant d’ouvrir le concepteur. La build compile l'application afin que le concepteur puisse charger ses types. Regardez la fenêtre de sortie et attendez que la construction soit réussie. Si la construction échoue, résolvez les erreurs avant de poursuivre la mise en page.

Dans Solution Explorer, double-cliquez sur Window1 pour ouvrir sa vue de conception. C'est la surface sur laquelle nous disposons les contrôles. Le concepteur enregistre sa mise en page dans Window1.Designer.cs. Conservez ce fichier généré sous le contrôle du concepteur ; écrivez le comportement de l'écran dans Window1.cs.

Faites glisser les contrôles du Toolbox vers la fenêtre. Une étiquette demande le nom de l'utilisateur, une zone de texte accepte la réponse et un bouton lancera le message d'accueil. Ajoutez une deuxième étiquette pour le résultat. Chaque contrôle a désormais un rôle clair dans l'interaction.

Définissez les Name et Text de chaque contrôle dans la fenêtre Propriétés. Name est l'identifiant utilisé par votre code ; Text est ce que l'utilisateur voit. Utilisez txtName pour la saisie, btnSayHello pour le bouton et lblStatus pour le résultat. L'étiquette d'en-tête est lblTitle.

Double-cliquez sur le bouton pour créer son gestionnaire Click. Lisez txtName.Text et coupez les espaces. Si le résultat est vide, définissez lblStatus.Text sur un message demandant un nom, puis revenez. Sinon, mettez le message d'accueil sur l'étiquette. La validation a lieu avant la réponse réussie.

Appuyez sur Démarrer pour exécuter l'application localement. Lorsque le navigateur s'ouvre, entrez un nom et cliquez sur Dites bonjour. Le gestionnaire Click s'exécute et l'étiquette de résultat affiche le message d'accueil. Vous avez connecté un écran visuellement conçu au code C# et vu la réponse dans le navigateur.

Dans cette leçon, nous allons créer un tableau de bord Wisej.NET dans le concepteur Visual Studio. Nous allons organiser ses contrôles, leur donner des noms significatifs et connecter un bouton à un gestionnaire Click. Vous verrez quel travail appartient à la mise en page générée et lequel appartient à votre propre code.

Ouvrez DashboardWindow en mode Création. Cette fenêtre rassemblera l'état du service, les commandes et l'historique des événements en un seul endroit, afin que les utilisateurs puissent comprendre le résultat de chaque action sans changer d'écran.

Utilisez le concepteur pour organiser les contrôles, le Toolbox pour les ajouter et la fenêtre Propriétés pour les configurer. Ces trois surfaces fonctionnent ensemble : sélectionnez un contrôle sur le canevas avant de modifier ses propriétés.

Ajoutez un en-tête et une étiquette d'état distincte, puis placez les trois étiquettes de service dans un panneau. Le panneau regroupe les informations associées, tandis que l'état général reste facile à trouver au-dessus.

Ajoutez les boutons Démarrer, Arrêter, Réinitialiser et Actualiser, suivis de la liste des événements. Les boutons lancent des actions ; la liste explique ce qui s'est passé. Garder cet historique visible facilite le suivi des actions répétées.

Définissez Text pour les mots que l'utilisateur voit et Name pour l'identifiant utilisé par votre code. Un nom tel que btnStart doit identifier l’objectif du contrôle, afin que son gestionnaire d’événements soit facile à localiser ultérieurement.

Double-cliquez sur Démarrer pour créer son gestionnaire de clics. Mettez à jour les étiquettes d'état et appelez un assistant pour ajouter l'événement. La réutilisation de l'assistant de journalisation permet de maintenir la cohérence de l'historique des événements entre les quatre commandes.

Écrivez le comportement dans le fichier C# standard de la fenêtre. Le concepteur conserve son propre fichier généré pour la création et la présentation des contrôles. Garder ces responsabilités séparées empêche une modification ultérieure de la conception d'écraser votre logique manuscrite.

Exécutez le projet et attendez que le navigateur s'ouvre. L'écran que vous avez conçu est désormais l'interface utilisateur de l'application en cours d'exécution. Vérifiez son état initial avant de tester les boutons.

Click Démarrez et regardez les trois étiquettes de service passer à En ligne. L'état général devient En cours d'exécution et la liste d'événements enregistre l'action. Ces changements visibles doivent s’accorder les uns avec les autres.

Click Arrêtez-vous ensuite. Chaque service devient hors ligne et une nouvelle entrée enregistre l'arrêt. Conserver l'entrée de démarrage antérieure permet à l'utilisateur de voir la séquence d'actions plutôt que seulement l'état actuel.

Click Réinitialiser pour ramener la démonstration à son état initial. Les entrées de journal précédentes disparaissent et l'état devient Inactif. Enregistrez la réinitialisation elle-même afin que l'historique vide ait une explication compréhensible.

Enfin, cliquez sur Actualiser pour relire l'état actuel et ajouter une entrée de journal. L'actualisation vérifie l'état ; cela ne signifie pas démarrer ou réinitialiser. Des commandes distinctes doivent produire des résultats distincts et compréhensibles.

Nous allons créer un shell partagé pour l'application afin que chaque page utilise la même navigation et la même mise en page. L'en-tête, la zone de navigation, la région de contenu et la barre d'état ont chacun un rôle clair. La centralisation des modifications de page nous donne également un seul endroit pour refléter les autorisations de l'utilisateur actuel dans la navigation.

Regardez le cadre extérieur rester en place pendant que la vue centrale change. Ce shell partagé donne à chaque fonctionnalité un accueil cohérent et évite de reconstruire la navigation sur chaque écran.

Organisez l'en-tête, la navigation, la zone de contenu et la barre d'état en tant que régions distinctes. Chacun a une responsabilité différente : s'orienter, choisir une fonctionnalité, effectuer le travail et rendre compte du résultat.

Ancrez l'en-tête en haut, la navigation à gauche et la barre d'état en bas. Laissez le contenu remplir l'espace restant afin que le redimensionnement préserve la structure globale.

Acheminez chaque bouton de navigation via NavigateTo. Une seule méthode peut appliquer les mêmes règles de changement de page de manière cohérente ; des implémentations distinctes dans chaque bouton dériveraient à mesure que des fonctionnalités seraient ajoutées.

Suivez NavigateTo tout au long du changement de page : supprimez le contenu précédent, chargez la vue sélectionnée, puis mettez à jour le fil d'Ariane et le statut. Le retour de navigation doit décrire la vue réellement affichée.

Les paramètres restent visibles pour l'agent de support, mais l'enregistrement est désactivé dans cette démonstration. Ceci illustre une autorisation dans l'interface ; le travail d'authentification ultérieur doit également appliquer l'autorisation réelle.

Le shell sépare désormais la navigation partagée des vues de fonctionnalités réutilisables. Lors de l'ajout d'une page, connectez-la via la même méthode de navigation et vérifiez que son emplacement et son statut restent clairs.

Nous afficherons une liste de tickets dans un DataGridView et connecterons le ticket sélectionné aux contrôles de détail. Un service fournira les données, tandis que l'écran coordonnera la sélection et l'affichage. Cette séparation maintient la base de données et les décisions commerciales hors des gestionnaires d'événements de l'interface utilisateur.

Construisez l'éditeur de tickets autour d'un modèle de données partagé plutôt que de copier des valeurs entre des contrôles non liés. La liaison connecte l'enregistrement sélectionné à l'écran, tandis que le service gère les opérations de ticket.

Placez les champs de détail à gauche et laissez la grille de tickets remplir le côté droit du conteneur divisé. Les utilisateurs peuvent sélectionner un enregistrement et inspecter ses détails sans quitter la liste.

Le ticket décrit les champs d'un enregistrement. TicketService fournit des opérations telles que le chargement et la sauvegarde. L'écran appelle ces opérations au lieu de devenir le lieu où les règles de persistance sont implémentées.

Connectez la liste et la grille via un BindingSource, puis liez les champs de détail à cette même source. Le partage de l'enregistrement actuel maintient le titre, le statut, la priorité et la description alignés sur la sélection.

Enregistrez d'abord via TicketService, puis informez le système de liaison avec ResetBindings. L'actualisation de l'affichage est distincte de la sauvegarde des données : une grille mise à jour à elle seule ne prouve pas que la persistance a réussi.

Exécutez l’éditeur et sélectionnez différentes lignes de ticket. Regardez les champs de détail suivre la sélection via BindingSource. Cela confirme que la grille et l'éditeur partagent le même enregistrement actuel.

Modifiez le statut du ticket sélectionné et cliquez sur Enregistrer le ticket. Suivez l’opération dans le service et revenez à la grille actualisée. La ligne visible devrait maintenant refléter la valeur que vous avez enregistrée.

Gardez les responsabilités en matière de modèle, de service et d’écran distinctes. Lorsqu'une valeur semble erronée, cette séparation vous pose une question utile : l'enregistrement est-il erroné, la sauvegarde a-t-elle échoué ou l'affichage est-il périmé ?

Nous utiliserons une boîte de dialogue pour créer un ticket ou en modifier un existant. La boîte de dialogue vérifie les champs obligatoires et signale la réussite uniquement une fois l'opération réussie. Les opérations sur les tickets restent dans la couche de service, donc les mêmes règles s'appliquent quel que soit l'écran qui ouvre la boîte de dialogue.

Créez une boîte de dialogue ciblée pour saisir un ticket et en modifier un existant. Donnez des résultats distincts pour Enregistrer et Annuler afin que la fermeture de la boîte de dialogue n'implique jamais silencieusement que les données ont été acceptées.

Regroupez les champs du ticket dans la boîte de dialogue et gardez Enregistrer et Annuler faciles à trouver. La boîte de dialogue doit collecter une modification cohérente, avec suffisamment d'informations pour que l'utilisateur puisse l'examiner avant de l'accepter.

Initialisez la même boîte de dialogue différemment pour chaque flux de travail. Nouveau commence avec une entrée vide ; Modifier charge le ticket sélectionné. La réutilisation de la mise en page permet de conserver la cohérence des deux flux de travail sans confondre leurs états de départ.

Exécutez ValidateForm avant de renvoyer un résultat accepté. Si les valeurs requises sont manquantes, laissez la boîte de dialogue ouverte. DialogResult.OK doit communiquer une entrée acceptée valide, pas simplement que le bouton Enregistrer a été enfoncé.

Ouvrez Nouveau et essayez d'enregistrer sans titre. Le message identifie les informations manquantes et la boîte de dialogue reste ouverte, donnant à l'utilisateur la possibilité de corriger la saisie sans redémarrer l'opération.

Remplissez les champs obligatoires et acceptez la boîte de dialogue. Le parent appelle ensuite TicketService et actualise la grille. Suivez cet ordre pour que l'utilisateur voie le résultat de la modification acceptée et enregistrée.

Sélectionnez un ticket existant et ouvrez Modifier. Ses valeurs actuelles devraient apparaître dans la même boîte de dialogue. Modifiez un champ, enregistrez et vérifiez que la ligne correspondante est mise à jour plutôt que de créer un autre ticket.

Utilisez la même séquence pour les deux workflows : valider, accepter, enregistrer via le service et actualiser. Garder ces étapes explicites facilite la gestion des échecs d’annulation et de validation sans écritures accidentelles.

Nous exécuterons une simulation d’exportation ou d’importation en arrière-plan et afficherons sa progression sans bloquer l’interface. Chaque utilisateur connecté conservera son propre état de fonctionnement. Nous traiterons également les échecs avec un message utile pour l'utilisateur tout en gardant les détails des erreurs internes hors de l'écran.

Utilisez la démonstration d’exportation et d’importation pour suivre une tâche au fil du temps. Un écran réactif a besoin de plus qu'une barre de progression : les utilisateurs doivent comprendre si le travail est en cours, terminé, annulé ou échoué.

Gardez les commandes de démarrage, l'annulation, la progression et le journal visibles ensemble. Ils répondent à différentes questions : que puis-je faire, où en est le travail et que s’est-il déjà passé ?

Dans RunJobAsync, attendez chaque étape et signalez sa progression. Utilisez le gestionnaire d'erreurs pour les échecs et le bloc finally pour le nettoyage, afin que l'interface puisse quitter son état occupé même en cas d'échec du travail.

Démarrez l'importation et observez les contrôles changer pendant l'exécution du travail. Désactivez les commandes qui entreraient en conflit avec l'opération active, mais gardez la progression et les commentaires disponibles afin que l'utilisateur puisse suivre le travail.

Conservez la progression et d’autres valeurs spécifiques à l’utilisateur dans la session en cours. Un champ statique est partagé entre les utilisateurs, donc y stocker l’état du travail d’une personne pourrait permettre à une autre personne de le voir ou de le modifier.

Activez Simuler l'erreur et exécutez à nouveau le travail. Conservez les détails du diagnostic dans le journal à des fins d'enquête, pendant que l'utilisateur reçoit un bref message de sécurité. Les détails de l’exception technique ne doivent pas devenir un texte d’erreur public.

Le bouton lance l'opération, le travail effectue le travail et l'écran signale son état. Gardez ces rôles séparés afin que le succès, l’annulation et l’échec puissent tous remettre l’interface dans un état utilisable.

Nous mettrons à jour l'apparence du tableau de bord à l'aide d'un thème intégré, de cartes et d'une navigation cohérente. Les services existants, la validation et la liaison de données continueront de faire leur travail. Cela nous permet d'améliorer la façon dont les utilisateurs lisent et naviguent sur l'écran sans réécrire le comportement commercial de l'application.

Modernisez l'écran existant sans reconstruire son comportement. Un thème Wisej.NET offre des choix visuels cohérents ; les améliorations de la mise en page et de la navigation rendent ensuite l'application plus facile à comprendre.

Rendez le titre de la page facile à identifier, regroupez les métriques associées et placez les commandes à côté du contenu qu'elles affectent. La hiérarchie visuelle devrait aider les utilisateurs à décider où chercher et quoi faire ensuite.

Le sélecteur de thème change Application.Theme.Name, tandis que SetActiveButton marque l'élément de navigation sélectionné. Traitez l'apparence et l'emplacement comme des préoccupations distinctes afin que les utilisateurs sachent toujours où ils se trouvent après avoir changé de thème.

Basculez entre les thèmes intégrés et comparez les mêmes commandes. Leur apparence change tandis que le flux de travail reste le même. Vérifiez la lisibilité et les états actifs plutôt que de juger le thème uniquement par ses couleurs.

Examinez le tableau de bord terminé dans son ensemble. Un espacement, des cartes et une navigation cohérents doivent prendre en charge la liaison et la validation des données existantes. Un rafraîchissement visuel réussit lorsque le flux de travail familier devient plus clair.

Nous ajouterons une petite visualisation d'état JavaScript à un écran Wisej.NET. Les contrôles natifs géreront toujours l’interaction ordinaire et C# sera propriétaire des données, des décisions et de la journalisation. Le widget affichera les valeurs qu'il reçoit, nous donnant un visuel spécialisé sans créer une deuxième source d'état de l'application.

Ajoutez une petite visualisation JavaScript à l'application Wisej.NET existante. Conservez la logique principale en C# afin que le visuel supplémentaire ne devienne pas le deuxième propriétaire des décisions de l'application.

Utilisez les étiquettes, les boutons et la journalisation natifs Wisej.NET pour une interaction ordinaire. Introduisez un Widget uniquement pour le visuel spécialisé. Cela permet de concentrer l'intégration au lieu de remplacer les contrôles qui résolvent déjà le problème.

Envoyez au widget uniquement les valeurs d'affichage dont il a besoin : statut, nombre de tickets et charge du système. C# reste responsable de ces valeurs ; la visualisation du navigateur les présente sans recevoir de données de serveur non liées.

Le gestionnaire de boutons met à jour les étiquettes natives et envoie les mêmes données via UpdateWidget. L’utilisation d’un seul résultat pour les deux présentations empêche le texte et la visualisation de décrire différents états.

Click Actualisez les données du serveur et comparez les étiquettes avec le widget. Ils devraient changer ensemble à partir de la même opération de serveur. S’ils ne sont pas d’accord, inspectez les données transmises à travers la limite d’intégration.

Essayez tour à tour Sain, Avertissement et Critique. Les événements C# mettent à jour l'état visuel et enregistrent la modification. L'historique des événements permet d'expliquer pourquoi le widget a son apparence actuelle.

Nous examinerons l’application avant de la conditionner pour sa publication. La configuration, les secrets, la journalisation et les autorisations nécessitent chacun une vérification explicite. Le workflow de publication utilisera ces vérifications pour décider si le package est prêt, tout en gardant les détails confidentiels hors des messages destinés aux utilisateurs.

Utilisez l'écran de révision pour recueillir des preuves avant la publication. Les contrôles de configuration, de sécurité et de déploiement appartiennent à un processus reproductible, de sorte que la préparation dépend des contrôles effectués plutôt que d'une impression rassurante.

Enregistrez d'abord l'environnement, la cible d'hébergement, la version et le réviseur. Ces détails identifient exactement ce qui est examiné ; une liste de contrôle complétée pour un environnement ne couvre pas automatiquement une cible de version différente.

Effectuez les vérifications de configuration requises séparément des notes facultatives. Une note peut expliquer une exception, mais elle ne doit pas faire disparaître une vérification requise manquante de la décision de préparation.

Gardez les secrets et les exceptions détaillées hors de l’écran de révision. Affichez un résumé sécurisé et laissez les détails du diagnostic dans les journaux du serveur, afin que le package de révision puisse être partagé sans exposer les informations d'identification.

Séparez l’état de préparation de l’autorisation. Les vérifications requises déterminent si la révision est terminée, tandis qu'une vérification du rôle détermine qui peut créer le package. La réussite de la liste de contrôle n'accorde pas à l'utilisateur une autorité supplémentaire.

Complétez les éléments requis restants et regardez le décompte atteindre neuf sur neuf. Le statut passe à Prêt pour révision. Cela signifie que la liste de contrôle est complète et non que le déploiement a déjà eu lieu.

Créez le package de révision et inspectez son résumé, y compris les problèmes connus et les informations de restauration. Un transfert utile indique au réviseur ce qui est prêt, ce qui reste incertain et comment récupérer en cas d'échec de la publication.

Module dix. Créez le mini service d'assistance Wisej.NET. Ce projet final rassemble le cours en une seule application. Nous suivrons sa navigation, le flux de travail des tickets et les écrans de support, puis examinerons ce qui rend le projet prêt à être examiné et déployé.

Commencez par l’application terminée et suivez son shell de navigation. Les exemples de cours distincts partagent désormais une seule présentation, afin que les utilisateurs puissent passer d'une fonctionnalité à l'autre sans apprendre à chaque fois un nouveau modèle de navigation.

Suivez les tickets, les clients et les tâches à travers leurs principales interactions. Les grilles présentent les enregistrements, les boîtes de dialogue collectent les modifications et les tâches en arrière-plan rendent compte de la progression. Après chaque action, vérifiez que le résultat visible explique ce qui s’est réellement passé.

Suivez un changement de ticket à travers ses responsabilités. La boîte de dialogue valide la saisie, TicketService gère l'opération et la grille présente le résultat. Des étiquettes et des messages d'état cohérents relient ces étapes pour l'utilisateur.

Utilisez le déploiement et l'architecture pour expliquer l'application au-delà de ses écrans. Passez en revue la configuration, la sécurité et la journalisation, puis tracez les données via la couche de service. Une démonstration de travail doit également rendre son organisation compréhensible.

Terminez avec la révision du code et les étapes suivantes. Vérifiez les noms pertinents et les responsabilités claires, puis enregistrez le travail de production restant. Le projet final démontre une application fonctionnelle tout en rendant explicites les travaux inachevés et les décisions de conception.