Theming und responsive Layouts

Erstellen Sie die Adaptive Operations Console, indem Sie das Erscheinungsbild vom Layout trennen. Im visuellen System Wisej.NET hilft Ihnen das Wissen, welcher Layer eine Entscheidung besitzt, dabei, die Anwendung konsistent zu ändern, anstatt einzelne Steuerelemente einzeln zu reparieren.

Folgen Sie der Darstellungstaste von einem Serversteuerelement zum Thema und dann zum Browser-Widget. Der Schlüssel wählt die visuelle Definition aus, sodass sich eine Designänderung auf jedes Steuerelement auswirken kann, das dieses Erscheinungsbild verwendet.

Ein Thema beschreibt Farben, Schriftarten, Bilder, Erscheinungsbilder, Zustände, Stile und Eigenschaften in einer strukturierten Datei. Benannte Farb- und Schriftarten-Tokens verbinden diese Definitionen und machen eine visuelle Auswahl für alle Steuerelemente, Widget-Metriken und Designer-Vorschauen wiederverwendbar.

Unterscheiden Sie Themenentscheidungen, Serversteuerungseigenschaften und direktes Browser-Styling. Verwenden Sie das Design für ein gemeinsames Erscheinungsbild, Steuereigenschaften für das relevante Verhalten und Layout sowie bereichsbezogene kaskadierende Stylesheets nur dann, wenn eine browserspezifische Regel gerechtfertigt ist.

Ein fester Schaltflächenhintergrund beschreibt nur einen visuellen Wert, sodass das Hover- und Druckverhalten ungelöst bleibt. Wählen Sie einen Darstellungsschlüssel für diese Zustände, eine Klasse für die Metrikkarte, einen Inline-Stil für einen berechneten Wert und Andocken für die Platzierung.

Docken Sie die Symbolleiste oben, den Status unten, die Navigation links, die Details rechts und den Arbeitsbereich im verbleibenden Bereich an. Geben Sie dem Arbeitsbereich eine Mindestgröße und verwenden Sie das Größenänderungsereignis der den Ansichtsbereich füllenden Seite, um die Browserbreite zur Überprüfung zu melden.

Machen Sie eine Bestandsaufnahme der visuellen Entscheidungen, bevor Sie ein Thema bearbeiten. Zeichnen Sie die Steuerelemente, zehn Farbtokens, drei Schriftartentokens, fünf Bereiche und sechs Haltepunkte auf und weisen Sie jedem Element einen Besitzer zu, damit spätere Änderungen in die entsprechende Ebene übernommen werden.

Schränken Sie den Browser auf die Breite des Tablets ein und beobachten Sie die Breitenanzeige und die angedockten Bereiche. Das Detailfenster wird herausgeschoben, wodurch die Grenzen dieser Desktop-Shell deutlich werden: Das Andocken allein hat noch nicht definiert, wie sich der Arbeitsablauf anpasst.

Stellen Sie für die erste Übung die Fünf-Regionen-Shell, das aufgezeichnete Basisthema, die visuelle Bestandsaufnahme und den Status in Browserbreite bereit. Dadurch wird eine sichtbare Basislinie erstellt, deren aktuelle Einschränkungen mit den reaktionsfähigen Verbesserungen in späteren Modulen verglichen werden können.

Erstellen Sie AdaptiveOps aus einem vorhandenen Basisthema, damit die Konsole eine vollständige visuelle Grundlage übernimmt. Mit dem Theme Builder können Sie die Identität der Anwendung zentral ausdrücken, anstatt ihr Erscheinungsbild durch verstreute Zuweisungen von Steuerelementen und Eigenschaften neu zu erstellen.

Durch die Wiederholung einer Markenfarbe über viele lokale Überschreibungen hinweg wird die Koordinierung der einzelnen Anpassungen erschwert und es werden immer noch Interaktionszustände übersehen. Ein zentrales Thema gibt der Farbe und ihrem Zustandsverhalten eine gepflegte Definition, anstatt sie an die interne Browserstruktur zu binden.

Untersuchen Sie Farben, Bilder, Schriftarten und Erscheinungsbilder als separate Themenabschnitte. Innerhalb eines Erscheinungsbilds definieren Zustände und Komponenten Stile und Widget-Eigenschaften; Wenn Sie diese Struktur verstehen, erfahren Sie, wo eine Änderung hingehört und was die Anwendung überschreiben kann.

Click die Vorschau, um den Darstellungspfad durch „Zuletzt angeklickt“ zu ermitteln, bevor Sie ihn bearbeiten. Verwenden Sie die Baumstruktur, um die Struktur und das Eigenschaftsraster zu finden, um Werte zu ändern, und überprüfen Sie dann die Live-Vorschau, um zu bestätigen, dass das gewünschte Steuerelement geändert wurde.

Lassen Sie die Aktionsschaltfläche die Basisschaltfläche erben und nur die vorgesehenen drei Zustände überschreiben. Fokussiertes und behindertes Verhalten bleibt vererbt; Überprüfen Sie zunächst die Statusreihenfolge mit der Standardeinstellung, bevor Sie eine Farbe ändern, die möglicherweise aus einem späteren Status stammt.

Definieren Sie die zehn benannten Farben und drei Schriftarten einmal und referenzieren Sie diese Namen dann anhand der Erscheinungsbilder. Das primäre Blau und der akzentuierte Bernstein werden zu gemeinsamen Token, sodass zukünftige Markenänderungen nicht die Suche nach wiederholten Hexadezimalwerten im gesamten Thema erfordern.

Wählen Sie das Startthema in Default.json aus und verwenden Sie Application.Theme, wenn Sie nur die aktuelle Sitzung ändern. Weisen Sie die Aktionsschaltfläche dem primären Befehl zu und entfernen Sie den festen Hintergrund, andernfalls kann die lokale Überschreibung das beabsichtigte Erscheinungsbild des Themas verbergen.

Schalten Sie die Konsole auf AdaptiveOps um und überprüfen Sie mehr als die Standardfarben. Bewegen Sie den Mauszeiger und drücken Sie „Speichern“, überprüfen Sie den ungültigen Editor und lesen Sie den Theme-Status, damit die Demonstration das Statusverhalten sowie die erfolgreiche Theme-Auswahl überprüft.

Erstellen Sie das tokenisierte Design und die gewünschten Erscheinungsbilder, einschließlich der Aktionsschaltfläche, und testen Sie sie dann sowohl in der Vorschau als auch in der Konsole. Wenn Sie sehen, dass in diesen beiden Kontexten dieselben Definitionen funktionieren, können Sie Überschreibungen oder fehlende Zustände vor der Übergabe erkennen.

Vergleichen Sie drei Möglichkeiten, die gleiche Messkarte zu gestalten, indem Sie fragen, wer das Ergebnis behält. Das Erscheinungsbild eines Themas, eine benannte Klasse und ein Inline-Stil sehen heute möglicherweise identisch aus, schaffen jedoch sehr unterschiedliche Verantwortlichkeiten für zukünftige Änderungen.

Verwenden Sie ein Erscheinungsbild für eine wiederverwendbare visuelle Variante und eine Klasse für eine durchsuchbare anwendungsspezifische Regel. Wiederholte anonyme Inline-Überschreibungen haben keine gemeinsame Definition, sodass jedes kopierte Panel zu einem weiteren Ort wird, der bei Designänderungen verschoben werden kann.

Wählen Sie den Eigentümer aus, bevor Sie den Stil schreiben: Thema für Standardsteuerelemente, Darstellungsschlüssel für Bedeutung, Klasse für anwendungsspezifische Schnittstelle und Inline-Stil für einen berechneten Wert. Entfernen Sie widersprüchliche Überschreibungen, die den ausgewählten Eigentümer daran hindern, das Ergebnis tatsächlich zu kontrollieren.

Der Befehl „Zuweisen“ drückt seine Rolle mit der Aktionsschaltfläche aus, während das Thema seine Zustände bereitstellt. Ebenso beschreibt ein Status einer veralteten Zeile die Präsentation; Die Anwendung muss weiterhin Eigentümer der zugrunde liegenden Geschäftsdaten sein, anstatt sie aus einer Farbe abzuleiten.

Ersetzen Sie vier kopierte Stile durch die gemeinsam genutzte Metrikkartenklasse. Behalten Sie die berechneten 72 Prozent des Service-Level-Agreement-Balkens als einzelnen Inline-Wert bei und verwenden Sie einen thematischen veralteten Status, um Daten darzustellen, deren Bedeutung im Modell erhalten bleibt.

Unterscheiden Sie die Startkonfiguration, das ausgewählte Thema einer Sitzung und die Mutation eines gemeinsam genutzten Themenobjekts. Durch das Bearbeiten des freigegebenen Objekts ändert sich, was andere Sitzungen sehen. Daher muss bei der persönlichen Auswahl des Dunkelmodus ein separates Thema ausgewählt werden, anstatt die gemeinsame Definition zu ändern.

Laden Sie das benannte dunkle Thema, weisen Sie es Application.Theme zu und merken Sie sich die Präferenz in der aktuellen Sitzung. Behandeln Sie eine fehlende Datei explizit. Die Startkonfiguration bleibt unverändert, da diese Auswahl zu einer Sitzung gehört.

Überprüfen Sie Karten, Abzeichen, den Hauptbefehl und die veraltete Reihe und vergleichen Sie dann zwei Sitzungen nebeneinander. Danas dunkle Auswahl sollte Priyas helles Thema intakt lassen und einen direkten Beweis dafür liefern, dass der Wechsel sitzungsspezifisch ist.

Stellen Sie das bereichsbezogene Stylesheet, einen berechneten Inline-Stil, das Erscheinungsbild semantischer Befehle, den veralteten Status und einen Nur-Sitzungs-Schalter bereit. Erklären Sie den Besitzer jeder Auswahl, damit die Überprüfung sowohl die Wartbarkeit als auch die Isolation zwischen Benutzern überprüfen kann.

Ersetzen Sie die Größenänderungskoordinatenberechnungen der Konsole durch Containerbeziehungen. Wenn das Layout beschreibt, welcher Bereich zu jeder Kante gehört und welcher den Rest ausfüllt, ist für die Größenänderung nicht mehr ein neuer Satz manueller Positionen für jede Breite erforderlich.

Die Desktop-Koordinaten sehen korrekt aus, bis das Ansichtsfenster kleiner wird. Verankerte Details überlappen den festen Arbeitsbereich und die Ansicht „Blätter speichern“, was zeigt, dass jedes zusätzliche Koordinatenfeld ein Symptom behandelt, ohne zu definieren, wie die Regionen den begrenzten Raum teilen sollen.

Docken Sie untergeordnete Elemente in der vorgesehenen Reihenfolge an, damit Randbereiche Platz beanspruchen, bevor der Arbeitsbereich den verbleibenden Platz ausfüllt. Durch das Auffüllen wird das verfügbare Anzeigerechteck reduziert. margin erzeugt keine Andocklücken, verwenden Sie daher die Eigenschaft, die die Layout-Engine tatsächlich liest.

Vermeiden Sie eine Größenänderungsschleife, bei der ein automatisch dimensioniertes übergeordnetes Element von daran angedockten untergeordneten Elementen abhängt. Lassen Sie stattdessen übergroße Inhalte scrollen und verwenden Sie minimale und maximale Größen, um sinnvolle Grenzen auszudrücken, ohne die gesamte Hierarchie zu zwingen, ihre Größe um sich selbst zu ändern.

Erstellen Sie die fünf angedockten Bereiche mit acht Pixeln Seitenabstand und Mindestgrößen für Arbeitsbereich und Raster. Sobald das Containerlayout über eine Größenänderung verfügt, entfernen Sie den alten Handler, damit zwei konkurrierende Mechanismen nicht mehr dieselbe Geometrie zuweisen.

Kapseln Sie den Detaileditor in einem UserControl, der über Bildlauffunktionen und interne Anker verfügt. Stellen Sie das Ticket und das gespeicherte Ereignis der Shell zur Verfügung. Dadurch bleibt das äußere Layout unabhängig von den einzelnen Textfeldern des Editors.

Grenzen Sie den Browser ein und überprüfen Sie das resultierende Verhalten: Die Schiene wird kompakt, Details scrollen und der Arbeitsbereich respektiert seine Mindestabmessungen. Der Punkt ist, dass Containerregeln dieses Ergebnis erzeugen, ohne den entfernten Resize-Koordinaten-Handler auszuführen.

Da es sich bei dem Detailbereich um einen eigenständigen UserControl handelt, kann die Shell ihn verschieben, ohne seine Interna neu zu erstellen. Docken Sie es für ein Tablet unter dem Raster an oder hosten Sie es in modaler Form für ein Telefon, wie spätere Profile es erfordern.

Stellen Sie eine verschachtelte Container-Shell mit bewusster Andockreihenfolge, Auffüllung, Größenbeschränkungen und einem Editor für Bildlaufdetails bereit. Extrahieren Sie die Navigations- und Detailsteuerelemente und entfernen Sie manuelle Begrenzungszuweisungen, damit Prüfer erkennen können, dass das Layout einen einzigen Eigentümer hat.

Die äußere Hülle wird jetzt korrekt angedockt, aber der Inhalt innerhalb jeder Region benötigt weiterhin eigene Layoutregeln. Vergleichen Sie Flow, Table und Flex anhand des Verhaltens, das der Inhalt erfordert, anstatt für jede Situation einen Container auszuwählen.

Karten und Felder verschwinden immer noch auf Tablet-Breite, da sie manuell in einer reaktionsfähigen Hülle positioniert werden. Entscheiden Sie, ob jede Region Elemente umschließen, Felder ausrichten oder den Raum proportional teilen soll, bevor Sie diese Koordinaten ersetzen.

Beobachten Sie die gleichen vier Karten unter jeder Engine, während das Ansichtsfenster kleiner wird. Flow umhüllt sie, feste Tischspalten drücken zusammen und das gezeigte Flex-Setup schneidet die letzte Karte ab; Diese Ergebnisse erklären, warum beim Verpacken von Karten, Formularen und proportionalen Bereichen unterschiedliche Auswahlmöglichkeiten erforderlich sind.

Erweiterte Eigenschaften beschreiben die Beteiligung eines untergeordneten Elements an seinem übergeordneten Layout. Konfigurieren Sie Flussgewichte und -unterbrechungen, Tischpositionen und -spannen oder flexible Gewichte und Ausrichtung durch den Container, damit das übergeordnete Element die Anweisungen erhält, die seine Engine versteht.

Überprüfen Sie, welche Engine den Abstand interpretiert, bevor Sie den Rand anpassen. Flow und Flex erzwingen es, Table wendet es innerhalb einer Zelle an und das Standard-Andocken ignoriert es; Padding ist der Mechanismus, der den verfügbaren Platz um angedockte Inhalte herum ändert.

Lassen Sie die Filterleiste umbrechen, geben Sie der Suche die verbleibende Breite und unterbrechen Sie sie nach Anwenden. Verwenden Sie für den Editor feste Beschriftungen neben einer flexiblen Feldspalte und sorgen Sie dafür, dass jedes Feld seine Zelle ausfüllt, wobei die Zeilen ausgerichtet bleiben, während sich die verfügbare Breite ändert.

Geben Sie den Dashboard-Bereichen eine Gewichtung von zwei zu eins, richten Sie sie oben aus und behalten Sie für jeden eine Mindestgröße bei. Die fließende Wisej.NET-Markup-Version drückt dieselben Beziehungen aus; Verwenden Sie innerhalb eines Containers konsistent eine Notation.

Ändern Sie die Größe von einem breiten Desktop zu einem schmalen Ansichtsfenster und befolgen Sie alle drei Verhaltensweisen. Karten sollten umbrochen werden, Editorspalten bleiben ausgerichtet und Details bleiben bei ihrer Mindestgröße stehen, was zeigt, dass jeder Container sein zugewiesenes Layoutproblem löst.

Erstellen Sie die Filterleiste, den Ticket-Editor und den Dashboard-Arbeitsbereich mit den entsprechenden Containern, indem Sie beispielsweise Fluent-Erweiterungen verwenden. Erfassen Sie verkleinerte Ergebnisse und erläutern Sie die Auswahl für jede Region, damit in der Einreichung sowohl die Begründung als auch die funktionierenden Layouts deutlich werden.

Verleihen Sie der Konsole ein profilbewusstes Verhalten sowie eine flexible Geometrie. Ein Telefon benötigt eine andere Möglichkeit, um auf Navigation und Bearbeitung zuzugreifen. Daher verbindet dieses Modul die Client-Erkennung mit serverseitigen Präsentations- und Workflow-Änderungen.

Die in der Größe veränderbare Shell versucht immer noch, Desktop-Navigation, Karten, Raster und Details auf ein Telefon zu übertragen. Browser-Medienabfragen können sich auf das Design auswirken, sie können jedoch die angezeigte Sichtbarkeit der Serversteuerung und die Entscheidungen zum Öffnen von Formularen nicht selbst durchführen.

Profile werden von oben nach unten ausgewertet und die erste Übereinstimmung wird aktiv. Sie werden nicht zusammengeführt, also stellen Sie enge Bedingungen vor den breiten Desktop-Fallback. Andernfalls kann die allgemeine Regel verhindern, dass spätere Telefon- und Tablet-Regeln jemals ausgewählt werden.

Legen Sie im Designer responsive Eigenschaftswerte pro Profil für Sichtbarkeit, Anzeige, Andocken, Größe und Schriftart fest. Das Ausblenden von Telefonregionen oder das Verschieben von Tablet-Details unter das Raster gehört zu den deklarierten Werten, wenn kein prozedurales Verhalten erforderlich ist.

Verwenden Sie ResponsiveProfileChanged für Verhalten, das ein Eigenschaftswert nicht ausdrücken kann, z. B. das Öffnen eines modalen Editors oder das Koordinieren einer verzögerten Antwort. Wählen Sie die entsprechende Anwendungs- oder Steuerereignisquelle aus und konzentrieren Sie sich bei diesem Code auf wirklich prozedurale Änderungen.

Melden Sie sich einmal an, wenden Sie das aktive Profil beim Start an und wenden Sie das aktuelle Profil des Ereignisses an, wenn es sich ändert. Schützen Sie sich vor dem Öffnen eines zweiten Editors und kündigen Sie das Abonnement während der Entsorgung, damit wiederholte Benachrichtigungen nicht zu doppelten Fenstern oder verbleibenden Handlern führen.

Vergleichen Sie eine syntaktisch gültige Profildatei mit einer falsch breiten ersten Regel mit der schmal-zu-breiten Version. Der Fehler liegt in der Reihenfolge, nicht in der Dateisyntax: Telefon- und Tablet-Varianten müssen vor der allgemeinen Desktop-Regel getestet werden.

Ändern Sie die Größe über Desktop, Tablet und Telefon, während Sie die Statusanzeige lesen. Bestätigen Sie, dass jedes Profil seine entworfenen Werte aktiviert und dass beim Erreichen von „Telefon“ der modale Editor nur einmal und nicht einmal pro Größenänderungsbenachrichtigung geöffnet wird.

Stellen Sie die sechs bestellten Profile, vom Designer festgelegte Telefon- und Tablet-Werte und den Profiländerungshandler mit Statusberichten bereit. Demonstrieren Sie den Übergang zum Telefoneditor, damit bei der Überprüfung sowohl die deklarative Anpassung als auch das eine Verhalten überprüft werden, das Code erfordert.

Bewerten Sie die fertige Adaptive Operations Console als ein Produkt, das auch nach zukünftigen Änderungen verwendbar bleiben muss. Das Abschlussprojekt prüft die Zugänglichkeit, die Kosten für die Größenänderung und den Besitz visueller Regeln und verwandelt eine funktionierende Demonstration in ein wartbares, reaktionsfähiges System.

Das Thema, semantische Erscheinungsbilder, bereichsbezogene Stile, Container und Kundenprofile sind bereits vorhanden. Beweisen Sie jetzt, dass sie für jedes Profil zusammenarbeiten, mit Tastatur- und Touch-Zugriff, angemessener Größenänderung und Entscheidungen, die ein anderer Entwickler erklären kann.

Beginnen Sie mit dem Thema und seinen Erscheinungsvarianten. Verwenden Sie Cascading Style Sheets nur dort, wo es nötig ist, und berücksichtigen Sie dann Container und responsive Eigenschaften. Fügen Sie Profiländerungscode oder benutzerdefinierte Profile hinzu, wenn einfachere Optionen die Anforderung nicht ausdrücken können, und dokumentieren Sie diesen Grund.

ApplyProfile sollte für ein unverändertes Profil frühzeitig zurückkehren und endgültige Werte zuweisen, anstatt sie umzuschalten. Das macht wiederholte Anrufe stabil; Durch die Bereinigung werden Abonnements entfernt, während ein gemeinsamer Fokusrahmen die Tastatursichtbarkeit über die Fokuszustände des Themas hinweg beibehält.

Vergleichen Sie Desktop-, Tablet- und Telefonansichten mithilfe der Testmodus-Profilanzeige. Die Navigation ändert sich von Text über Symbole bis hin zu einem Menü, während Details von der Seite unterhalb des Rasters zu einem modalen Element verschoben werden, sodass der Zugriff über verschiedene Präsentationen hinweg erhalten bleibt.

Zeichnen Sie sechs reaktionsfähige Testfälle mit erwarteten Profilen, Screenshots und Überprüfungen auf Layout, Scrollen, Fokus, ungültige Zustände und Berührung auf. Wiederholen Sie diese Matrix nach Theme-Änderungen und -Upgrades, damit Regressionen mit expliziten Erwartungen und nicht mit der Erinnerung verglichen werden.

Behalten Sie den sichtbaren Fokus bei, ergänzen Sie Fehlerfarben durch Symbole oder Meldungen, kennzeichnen Sie Nur-Symbol-Aktionen und befolgen Sie die Tab-Reihenfolge. Überprüfen Sie die Größenbeschränkungen und die automatische Größenanpassung und versionieren Sie dann Theme, Stile und Profile gemeinsam, damit Zugänglichkeits- und Layoutänderungen einer Codeüberprüfung unterzogen werden.

Lassen Sie das Erdungspaket erklären, wie anhand der Kursnachweise und des Eigentümerentscheidungsbaums zu antworten ist. Markieren Sie instabile interne Dokumentselektoren und direkte Überschreibungen und fordern Sie das tatsächliche Profil und die Bildschirmgröße an, wenn das Reaktionsproblem noch nicht spezifisch genug ist.

Übergeben Sie die fertige Konsole mit wiederholbarem Profilhandler, Testindikator, Barrierefreiheitsprüfung, Orientierungsmatrix, Architekturhinweis und Erdungspaket. Zusammengenommen zeigen diese nicht nur, dass das aktuelle Layout funktioniert, sondern auch, wie die nächste Änderung bewertet wird.