Thèmes et mises en page responsives

Créez la console Adaptive Operations Console en séparant l'apparence de la présentation. Dans le système visuel Wisej.NET, savoir quelle couche possède une décision vous aide à modifier l'application de manière cohérente au lieu de corriger les contrôles individuels un par un.

Suivez la clé d'apparence depuis un contrôle serveur jusqu'au thème puis jusqu'au widget du navigateur. La clé sélectionne la définition visuelle, donc un changement de thème peut affecter tous les contrôles qui utilisent cette apparence.

Un thème décrit les couleurs, les polices, les images, les apparences, les états, les styles et les propriétés dans un seul fichier structuré. Les jetons de couleur et de police nommés connectent ces définitions, rendant ainsi un choix visuel réutilisable dans les contrôles, les métriques des widgets et les aperçus du concepteur.

Distinguez les décisions de thème, les propriétés de contrôle du serveur et le style direct du navigateur. Utilisez le thème pour l'apparence partagée, les propriétés de contrôle pour le comportement et la mise en page pertinents, ainsi que les feuilles de style en cascade étendues uniquement lorsqu'une règle spécifique au navigateur est justifiée.

Un arrière-plan de bouton fixe ne décrit qu'une seule valeur visuelle, laissant le comportement de survol et d'appui non résolu. Choisissez une clé d'apparence pour ces états, une classe pour la carte métrique, un style en ligne pour une valeur calculée et un ancrage pour le placement.

Ancrez la barre d'outils ci-dessus, l'état ci-dessous, la navigation à gauche, les détails à droite et l'espace de travail dans la zone restante. Donnez à l'espace de travail une taille minimale et utilisez l'événement de redimensionnement de la page de remplissage de la fenêtre pour signaler la largeur du navigateur à des fins d'inspection.

Inventoriez les décisions visuelles avant de modifier un thème. Enregistrez les contrôles, dix jetons de couleur, trois jetons de police, cinq régions et six points d'arrêt, en attribuant à chaque élément un propriétaire afin que les modifications ultérieures soient transférées au calque approprié.

Affinez le navigateur à la largeur de la tablette et observez l'indicateur de largeur et les régions ancrées. Le panneau de détails est repoussé, exposant les limites de cette coque de bureau : l'ancrage à lui seul n'a pas encore défini la manière dont le flux de travail s'adapte.

Pour le premier atelier, fournissez le shell à cinq régions, le thème de base enregistré, l'inventaire visuel et l'état de la largeur du navigateur. Cela établit une base de référence visible dont les limites actuelles peuvent être comparées aux améliorations réactives des modules ultérieurs.

Créez AdaptiveOps à partir d'un thème de base existant afin que la console hérite d'une base visuelle complète. Le Theme Builder vous permet d'exprimer l'identité de l'application de manière centralisée au lieu de reconstruire son apparence via des affectations de propriétés de contrôle dispersées.

La répétition d’une couleur de marque sur de nombreux remplacements locaux rend chaque ajustement plus difficile à coordonner et manque toujours les états d’interaction. Un thème central donne à la couleur et à son comportement d'état une définition conservée au lieu de les lier à la structure interne du navigateur.

Inspectez les couleurs, les images, les polices et les apparences dans des sections thématiques distinctes. Au sein d'une apparence, les états et les composants définissent les styles et les propriétés du widget ; comprendre cette structure vous indique à quoi appartient un changement et ce que l'application peut remplacer.

Click l'aperçu pour découvrir le chemin d'apparence via le dernier clic avant de le modifier. Utilisez l'arborescence pour localiser la structure et la grille de propriétés pour modifier les valeurs, puis vérifiez l'aperçu en direct pour confirmer que le contrôle prévu a été modifié.

Laissez le bouton d'action hériter du bouton de base et remplacer uniquement les trois états prévus. Les comportements concentrés et handicapés restent hérités ; inspectez d'abord l'ordre des états avec la valeur par défaut avant de modifier une couleur qui peut provenir d'un état ultérieur.

Définissez une fois les dix couleurs nommées et les trois polices, puis référencez ces noms à partir des apparences. Le bleu principal et l'ambre d'accent deviennent des jetons partagés, de sorte que les futurs changements de marque ne nécessitent pas de trouver des valeurs hexadécimales répétées dans le thème.

Sélectionnez le thème de démarrage dans Default.json et utilisez Application.Theme lorsque vous modifiez uniquement la session en cours. Attribuez le bouton d'action à la commande principale et supprimez son arrière-plan fixe, sinon le remplacement local peut masquer l'apparence prévue du thème.

Basculez la console sur AdaptiveOps et inspectez plus que ses couleurs par défaut. Passez la souris et appuyez sur Enregistrer, vérifiez l'éditeur non valide et lisez l'état du thème afin que la démonstration vérifie le comportement de l'état ainsi que la sélection réussie du thème.

Créez le thème tokenisé et ses apparences demandées, y compris le bouton d'action, puis testez-les à la fois dans l'aperçu et dans la console. Voir les mêmes définitions fonctionner dans ces deux contextes permet de détecter les remplacements ou les états manquants avant le transfert.

Comparez trois façons de styliser la même carte métrique en demandant qui conservera le résultat. Une apparence de thème, une classe nommée et un style en ligne peuvent sembler identiques aujourd'hui tout en créant des responsabilités très différentes pour les changements futurs.

Utilisez une apparence pour une variante visuelle réutilisable et une classe pour une règle spécifique à l'application consultable. Les remplacements en ligne anonymes répétés n'ont pas de définition partagée, de sorte que chaque panneau copié devient un autre endroit qui peut dériver lorsque la conception change.

Choisissez le propriétaire avant d'écrire le style : thème pour les contrôles standard, clé d'apparence pour la signification, classe pour l'interface spécifique à l'application et style en ligne pour une valeur calculée. Supprimez les remplacements conflictuels qui empêchent le propriétaire choisi de contrôler réellement le résultat.

La commande Assign exprime son rôle avec un bouton d'action, tandis que le thème fournit ses états. De même, un état de ligne obsolète décrit la présentation ; l'application doit toujours posséder les données métier sous-jacentes au lieu de les déduire d'une couleur.

Remplacez quatre styles copiés par la classe de carte métrique partagée. Conservez les soixante-douze pour cent calculés de la barre d'accord de niveau de service comme valeur en ligne unique et utilisez un état obsolète thématique pour présenter des données dont la signification reste dans le modèle.

Distinguez la configuration de démarrage, le thème sélectionné d'une session et la mutation d'un objet de thème partagé. La modification de l'objet partagé modifie ce que voient les autres sessions. Un choix personnel en mode sombre doit donc sélectionner un thème distinct plutôt que de modifier la définition partagée.

Chargez le thème sombre nommé, attribuez-le à Application.Theme et mémorisez la préférence dans la session en cours. Gérer explicitement un fichier manquant ; la configuration de démarrage reste inchangée car ce choix appartient à une seule session.

Inspectez les cartes, les badges, la commande principale et la ligne obsolète, puis comparez deux sessions côte à côte. La sélection sombre de Dana devrait laisser intact le thème clair de Priya, fournissant une preuve directe que le changement est spécifique à la session.

Fournissez la feuille de style étendue, un style en ligne calculé, une apparence de commande sémantique, un état obsolète et un commutateur de session uniquement. Expliquez le propriétaire de chaque choix afin que l'examen puisse vérifier à la fois la maintenabilité et l'isolement entre les utilisateurs.

Remplacez les calculs de redimensionnement et de coordonnées de la console par des relations de conteneur. Lorsque la mise en page décrit quelle région appartient à chaque bord et laquelle remplit le reste, le redimensionnement n'a plus besoin d'un nouvel ensemble de positions manuelles pour chaque largeur.

Les coordonnées du bureau semblent correctes jusqu'à ce que la fenêtre se rétrécisse. Les détails ancrés chevauchent l'espace de travail fixe et la vue Enregistrer les feuilles, montrant que chaque patch de coordonnées supplémentaire traite un symptôme sans définir comment les régions doivent partager un espace limité.

Ancrez les enfants dans l'ordre prévu afin que les régions périphériques consomment de l'espace avant que l'espace de travail ne remplisse ce qui reste. Le remplissage réduit le rectangle d'affichage disponible ; margin ne crée pas d'espace d'amarrage, utilisez donc la propriété que le moteur de mise en page lit réellement.

Évitez une boucle de dimensionnement dans laquelle un parent dimensionné automatiquement dépend des enfants qui y sont ancrés. Laissez plutôt défiler le contenu surdimensionné et utilisez des tailles minimales et maximales pour exprimer des limites utiles sans forcer l'ensemble de la hiérarchie à se redimensionner autour d'elle-même.

Créez les cinq régions ancrées avec huit pixels de remplissage de page et des tailles minimales pour l'espace de travail et la grille. Une fois que la disposition du conteneur est propriétaire du redimensionnement, supprimez l'ancien gestionnaire afin que deux mécanismes concurrents n'attribuent plus la même géométrie.

Encapsulez l'éditeur de détails dans un UserControl possédant des ancres de défilement et internes. Exposez le ticket et l'événement enregistré au shell ; cela maintient la mise en page extérieure indépendante des zones de texte individuelles de l'éditeur.

Affinez le navigateur et inspectez le comportement obtenu : le rail devient compact, les détails défilent et l'espace de travail respecte ses dimensions minimales. Le fait est que les règles de conteneur produisent ce résultat sans exécuter le gestionnaire de coordonnées de redimensionnement supprimé.

Étant donné que la région de détails est un UserControl autonome, le shell peut la déplacer sans reconstruire ses composants internes. Ancrez-le sous la grille pour une tablette ou hébergez-le sous une forme modale pour un téléphone, comme l'exigent les profils ultérieurs.

Fournissez une coque de conteneur imbriqué avec un ordre d'amarrage délibéré, un remplissage, des limites de taille et un éditeur de détails défilants. Extrayez les contrôles de navigation et de détails, et supprimez les affectations de limites manuelles afin que les réviseurs puissent voir que la mise en page a un seul propriétaire.

L'enveloppe extérieure s'ancre désormais correctement, mais le contenu à l'intérieur de chaque région nécessite toujours ses propres règles de mise en page. Comparez Flow, Table et Flex en fonction du comportement requis par le contenu plutôt que de choisir un conteneur pour chaque situation.

Les cartes et les champs disparaissent toujours à la largeur de la tablette car ils sont positionnés manuellement à l'intérieur d'un shell réactif. Décidez si chaque région doit envelopper les éléments, aligner les champs ou partager l'espace proportionnellement avant de remplacer ces coordonnées.

Regardez les quatre mêmes cartes sous chaque moteur à mesure que la fenêtre se rétrécit. Flow les enveloppe, les colonnes fixes de la table sont pressées et la configuration flexible affichée coupe la dernière carte ; ces résultats expliquent pourquoi l'emballage des cartes, des formulaires et des régions proportionnelles nécessitent des choix différents.

Les propriétés étendues décrivent la participation d'un enfant à sa mise en page parent. Configurez les poids et les ruptures de flux, les positions et les portées des tables, ou les poids flexibles et l'alignement dans le conteneur afin que le parent reçoive les instructions comprises par son moteur.

Vérifiez quel moteur interprète l’espacement avant d’ajuster la marge. Flow et Flex l'appliquent, Table l'applique à l'intérieur d'une cellule et l'ancrage par défaut l'ignore ; le remplissage est le mécanisme qui modifie l'espace disponible autour du contenu ancré.

Laissez la barre de filtre s'enrouler, donnez à la recherche la largeur restante et interrompez-la après Appliquer. Pour l'éditeur, utilisez des étiquettes fixes à côté d'une colonne de champ flexible et faites en sorte que chaque champ remplisse sa cellule, en gardant les lignes alignées pendant que la largeur disponible change.

Donnez aux régions du tableau de bord des poids de deux pour un, alignez-les en haut et conservez une taille minimale pour chacune. La version fluide de balisage Wisej.NET exprime les mêmes relations ; utilisez une notation de manière cohérente dans un conteneur.

Redimensionnez d'un bureau large à une fenêtre d'affichage étroite et suivez les trois comportements. Les cartes doivent s'enrouler, les colonnes de l'éditeur restent alignées et les détails s'arrêtent à leur taille minimale, démontrant que chaque conteneur résout le problème de mise en page qui lui est assigné.

Créez la barre de filtres, l'éditeur de tickets et l'espace de travail du tableau de bord avec leurs conteneurs appropriés, en utilisant des extensions fluides par exemple. Capturez les résultats redimensionnés et expliquez le choix pour chaque région afin que la soumission démontre le raisonnement ainsi que les présentations de travail.

Donnez à la console un comportement sensible au profil ainsi qu'une géométrie flexible. Un téléphone a besoin d'un moyen différent pour accéder à la navigation et à l'édition, c'est pourquoi ce module connecte la reconnaissance client à la présentation côté serveur et aux modifications du flux de travail.

Le shell redimensionnable essaie toujours d'adapter la navigation, les cartes, la grille et les détails du bureau à un téléphone. Les requêtes multimédias du navigateur peuvent affecter le style, mais elles ne peuvent pas effectuer elles-mêmes la visibilité du contrôle du serveur et les décisions d'ouverture de formulaire.

Les profils sont évalués de haut en bas et la première correspondance devient active. Ils ne fusionnent pas, placez donc des conditions précises avant le recours généralisé au bureau ; sinon, la règle générale peut empêcher la sélection ultérieure de règles sur les téléphones et les tablettes.

Définissez les valeurs des propriétés réactives par profil dans le concepteur pour la visibilité, l'affichage, l'ancrage, la taille et la police. Le masquage des régions du téléphone ou le déplacement des détails de la tablette sous la grille font partie de ces valeurs déclarées lorsqu'aucun comportement procédural n'est nécessaire.

Utilisez ResponsiveProfileChanged pour le comportement qu'une valeur de propriété ne peut pas exprimer, comme l'ouverture d'un éditeur modal ou la coordination d'une réponse retardée. Choisissez l’application ou la source d’événement de contrôle appropriée et concentrez ce code sur les changements véritablement procéduraux.

Abonnez-vous une fois, appliquez le profil actif au démarrage et appliquez le profil actuel de l'événement lorsqu'il change. Évitez d'ouvrir un deuxième éditeur et désabonnez-vous lors de la suppression afin que les notifications répétées ne créent pas de fenêtres en double ou de gestionnaires persistants.

Comparez un fichier de profil syntaxiquement valide avec une première règle incorrectement large avec la version étroite à large. L’échec vient de l’ordre, pas de la syntaxe des fichiers : les variantes de téléphones et de tablettes doivent être testées avant la règle générale du bureau.

Redimensionnez via l'ordinateur de bureau, la tablette et le téléphone tout en lisant l'indicateur d'état. Confirmez que chaque profil active ses valeurs conçues et que le fait d'atteindre le téléphone n'ouvre l'éditeur modal qu'une seule fois plutôt qu'une fois par notification de redimensionnement.

Fournissez les six profils commandés, les valeurs de téléphone et de tablette définies par le concepteur, ainsi que le gestionnaire de changement de profil avec rapport d'état. Démontrez la transition vers l'éditeur de téléphone afin que l'examen vérifie à la fois l'adaptation déclarative et le comportement qui nécessite du code.

Examinez la console Adaptive Operations Console terminée en tant que produit qui doit rester utilisable après de futures modifications. Le projet final vérifie l'accessibilité, le coût de redimensionnement et la propriété des règles visuelles, transformant une démonstration fonctionnelle en un système réactif maintenable.

Le thème, les apparences sémantiques, les styles étendus, les conteneurs et les profils clients sont déjà présents. Prouvez maintenant qu'ils fonctionnent ensemble pour chaque profil, avec un accès clavier et tactile, un travail de redimensionnement raisonnable et des décisions qu'un autre développeur peut expliquer.

Commencez par le thème et ses variantes d’apparence. Utilisez des feuilles de style en cascade uniquement lorsque cela est nécessaire, puis envisagez les conteneurs et les propriétés réactives. Ajoutez un code de changement de profil ou des profils personnalisés lorsque des options plus simples ne peuvent pas exprimer l'exigence, et documentez cette raison.

ApplyProfile devrait revenir plus tôt pour un profil inchangé et attribuer des valeurs finales plutôt que de les basculer. Cela rend les appels répétés stables ; le nettoyage supprime les abonnements, tandis qu'un cadre de focus partagé préserve la visibilité du clavier dans les états ciblés du thème.

Comparez les vues des ordinateurs de bureau, des tablettes et des téléphones à l'aide de l'indicateur de profil en mode test. La navigation passe du texte aux icônes en passant par un menu, tandis que les détails se déplacent du côté vers le dessous de la grille vers un modal, préservant l'accès à travers différentes présentations.

Enregistrez six cas de test réactifs avec les profils attendus, les captures d'écran et les vérifications de la disposition, du défilement, de la mise au point, des états non valides et du toucher. Répétez cette matrice après les changements de thème et les mises à niveau afin que les régressions soient comparées aux attentes explicites plutôt qu'à la mémoire.

Gardez le focus visible, complétez les couleurs d'erreur avec des icônes ou des messages, étiquetez les actions contenant uniquement des icônes et parcourez l'ordre de tabulation. Vérifiez les limites de taille et le dimensionnement automatique, puis le thème, les styles et les profils de version ensemble afin que les modifications d'accessibilité et de mise en page soient révisées par le code.

Demandez au dossier de base d'expliquer comment répondre à partir des preuves du cours et de l'arbre de décision de propriété. Signalez les sélecteurs de documents internes fragiles et les remplacements directs, et demandez le profil et la taille d'écran réels lorsque le problème de réponse n'est pas encore suffisamment spécifique.

Remettez la console terminée avec son gestionnaire de profil reproductible, son indicateur de test, son examen d'accessibilité, sa matrice d'orientation, sa note d'architecture et son pack de mise à la terre. Ensemble, ceux-ci montrent non seulement que la mise en page actuelle fonctionne, mais aussi comment le prochain changement sera évalué.