Foundations

Modulo uno. La tua prima applicazione Wisej.NET. Costruiremo una piccola schermata che chiede un nome e mostra un saluto. Questo esempio introduce il flusso di lavoro di base: progettare l’interfaccia, gestire un evento e verificare il risultato nel browser.

In Visual Studio, scegli Create a new project. Wisej.NET usa il consueto flusso di creazione dei progetti, con modelli che forniscono i file iniziali dell’applicazione. L’interfaccia verrà eseguita nel browser, mentre il codice dei nostri eventi verrà eseguito sul server.

Cerca Wisej.NET. Questa dimostrazione usa il modello Wisej.NET 4 Web Application con C#. Selezionalo e continua. Se non compare nella tua installazione, prima di procedere verifica che siano installati l’estensione Wisej.NET e i relativi modelli di progetto.

Scegli il nome del progetto e la cartella, quindi fai clic su Create. Visual Studio genera il progetto e la finestra iniziale. Guarda Solution Explorer: qui troverai i file dell’applicazione e potrai tornare alla finestra mentre costruisci la schermata.

Compila il progetto prima di aprire il designer. La compilazione permette al designer di caricare i tipi dell’applicazione. Controlla la finestra Output e attendi il messaggio Build succeeded. Se la compilazione fallisce, risolvi gli errori prima di proseguire con il layout.

In Solution Explorer, fai doppio clic su Window1 per aprire la vista di progettazione. Qui disporremo i controlli. Il designer ne registra il layout in Window1.Designer.cs. Lascia che sia il designer a gestire quel file generato e scrivi il comportamento della schermata in Window1.cs.

Trascina i controlli dalla Toolbox alla finestra. Un’etichetta chiede il nome dell’utente, una casella di testo riceve la risposta e un pulsante avvia il saluto. Aggiungi una seconda etichetta per il risultato. Ogni controllo ha ora un ruolo preciso nell’interazione.

Imposta Name e Text per ciascun controllo nella finestra Properties. Name è l’identificatore usato dal codice; Text è ciò che vede l’utente. Usa txtName per l’input, btnSayHello per il pulsante e lblStatus per il risultato. L’etichetta del titolo si chiama lblTitle.

Fai doppio clic sul pulsante per creare il gestore Click. Leggi txtName.Text ed elimina gli spazi iniziali e finali. Se il risultato è vuoto, assegna a lblStatus.Text un messaggio che chieda di inserire un nome e termina il gestore. Altrimenti, mostra il saluto nell’etichetta. La validazione avviene prima della risposta di successo.

Premi Start per eseguire l’applicazione in locale. Quando si apre il browser, inserisci un nome e fai clic su Say Hello. Il gestore Click viene eseguito e l’etichetta del risultato mostra il saluto. Hai collegato una schermata progettata visualmente al codice C# e ne hai visto la risposta nel browser.

In questa lezione costruiremo una dashboard Wisej.NET nel Designer di Visual Studio. Disporremo i controlli, assegneremo loro nomi significativi e collegheremo un pulsante a un gestore Click. Vedrai quali operazioni appartengono al codice di layout generato e quali al codice che scrivi tu.

Apri DashboardWindow in visualizzazione progettazione. Questa finestra raccoglierà lo stato del servizio, i comandi e la cronologia degli eventi in un unico posto, in modo che gli utenti possano comprendere il risultato di ciascuna azione senza cambiare schermata.

Utilizza la finestra di progettazione per organizzare i controlli, Toolbox per aggiungerli e la finestra Proprietà per configurarli. Queste tre superfici lavorano insieme: seleziona un controllo sull'area di disegno prima di modificarne le proprietà.

Aggiungi un'intestazione e un'etichetta di stato separata, quindi posiziona le tre etichette di servizio all'interno di un pannello. Il pannello raggruppa le informazioni correlate, mentre lo stato generale rimane facile da trovare sopra di esso.

Aggiungi i pulsanti Avvia, Interrompi, Reimposta e Aggiorna, seguiti dall'elenco degli eventi. I pulsanti avviano azioni; l'elenco spiega cosa è successo. Mantenere visibile la cronologia rende più facile seguire le azioni ripetute.

Imposta Text per le parole che l'utente vede e Name per l'identificatore utilizzato dal tuo codice. Un nome come btnStart dovrebbe identificare lo scopo del controllo, in modo che il suo gestore eventi sia facile da individuare in seguito.

Fare doppio clic su Start per creare il relativo gestore di clic. Aggiorna le etichette di stato lì e chiama un aiutante per aggiungere l'evento. Il riutilizzo dell'helper di registrazione mantiene la cronologia degli eventi coerente in tutti e quattro i comandi.

Scrivi il comportamento nel normale file C# della finestra. Il progettista conserva il proprio file generato per la creazione e il layout del controllo. Mantenere separate queste responsabilità impedisce che una successiva modifica alla progettazione sovrascriva la logica scritta a mano.

Esegui il progetto e attendi l'apertura del browser. La schermata che hai progettato è ora l'interfaccia utente dell'applicazione in esecuzione. Controlla il suo stato iniziale prima di testare i pulsanti.

Click Avvia e osserva le tre etichette dei servizi passare a Online. Lo stato generale diventa In esecuzione e l'elenco eventi registra l'azione. Questi cambiamenti visibili dovrebbero concordare tra loro.

Click Interrompi successivo. Ogni servizio diventa Offline e una nuova voce registra la fermata. Mantenere la voce di avvio precedente consente all'utente di vedere la sequenza di azioni anziché solo lo stato corrente.

Click Reset per riportare la dimostrazione al suo stato iniziale. Le voci di registro precedenti scompaiono e lo stato diventa Inattivo. Registra il ripristino stesso in modo che la cronologia vuota abbia una spiegazione comprensibile.

Infine, fai clic su Aggiorna per leggere nuovamente lo stato corrente e aggiungere una voce di registro. Aggiorna controlla lo stato; non significa Avvia o Ripristina. Comandi distinti dovrebbero produrre risultati distinti e comprensibili.

Costruiremo una struttura condivisa per l’applicazione, in modo che tutte le pagine usino la stessa navigazione e lo stesso layout. Intestazione, area di navigazione, contenuto e barra di stato avranno ciascuno un ruolo preciso. Centralizzare i cambi di pagina ci darà anche un unico punto in cui adattare la navigazione ai permessi dell’utente corrente.

Guarda il telaio esterno rimanere al suo posto mentre la vista centrale cambia. Questa shell condivisa fornisce a ciascuna funzionalità una posizione coerente ed evita di ricostruire la navigazione su ogni schermata.

Disporre l'intestazione, la navigazione, l'area del contenuto e la barra di stato come aree separate. Ognuno ha una responsabilità diversa: orientamento, scelta di una funzionalità, esecuzione del lavoro e reporting del risultato.

Ancora l'intestazione in alto, la navigazione a sinistra e la barra di stato in basso. Lascia che il contenuto riempia lo spazio rimanente in modo che il ridimensionamento preservi la struttura complessiva.

Indirizza ogni pulsante di navigazione attraverso NavigateTo. Un singolo metodo può applicare le stesse regole di cambio pagina in modo coerente; implementazioni separate in ciascun pulsante cambierebbero man mano che vengono aggiunte funzionalità.

Segui NavigateTo attraverso il cambio pagina: rimuovi il contenuto precedente, carica la visualizzazione selezionata, quindi aggiorna il breadcrumb e lo stato. Il feedback di navigazione deve descrivere la vista effettivamente visualizzata.

Le impostazioni rimangono visibili all'agente di supporto, ma il salvataggio è disabilitato in questa dimostrazione. Questo illustra un'autorizzazione nell'interfaccia; il successivo lavoro di autenticazione dovrà far valere anche l'effettiva autorizzazione.

La shell ora separa la navigazione condivisa dalle visualizzazioni delle funzionalità riutilizzabili. Quando aggiungi una pagina, collegala tramite lo stesso metodo di navigazione e controlla che la sua posizione e il suo stato rimangano chiari.

Mostreremo un elenco di ticket in una DataGridView e collegheremo il ticket selezionato ai controlli di dettaglio. Un servizio fornirà i dati, mentre la schermata coordinerà selezione e visualizzazione. Questa separazione mantiene le decisioni sul database e le regole di business fuori dai gestori degli eventi dell’interfaccia.

Costruisci l'editor di ticket attorno a un modello di dati condiviso anziché copiare valori tra controlli non correlati. Il bind collega il record selezionato alla videata, mentre il servizio gestisce le operazioni di ticket.

Posiziona i campi dei dettagli a sinistra e lascia che la griglia del biglietto riempia il lato destro del contenitore diviso. Gli utenti possono selezionare un record e controllarne i dettagli senza uscire dall'elenco.

Il ticket descrive i campi in un record. TicketService fornisce operazioni come caricamento e salvataggio. Lo schermo richiama tali operazioni invece di diventare il luogo in cui vengono implementate le regole di persistenza.

Collega l'elenco e la griglia tramite BindingSource, quindi associa i campi dei dettagli alla stessa origine. La condivisione del record corrente mantiene Titolo, Stato, Priorità e Descrizione allineati con la selezione.

Salvare prima tramite TicketService, quindi avvisare il sistema di rilegatura con ResetBindings. L'aggiornamento della visualizzazione è separato dal salvataggio dei dati: una griglia aggiornata da sola non dimostra il successo della persistenza.

Esegui l'editor e seleziona diverse righe di ticket. Guarda i campi di dettaglio seguire la selezione fino a BindingSource. Ciò conferma che la griglia e l'editor condividono lo stesso record corrente.

Modifica lo stato del biglietto selezionato e fai clic su Salva biglietto. Segui l'operazione nel servizio e torna alla griglia aggiornata. La riga visibile ora dovrebbe riflettere il valore salvato.

Mantieni distinte le responsabilità del modello, del servizio e dello schermo. Quando un valore sembra sbagliato, questa separazione pone una domanda utile: il record è sbagliato, il salvataggio non è riuscito o la visualizzazione è obsoleta?

Useremo un’unica finestra di dialogo per creare un ticket o modificarne uno esistente. La finestra controllerà i campi obbligatori e segnalerà il successo solo quando l’operazione sarà riuscita. Le operazioni sui ticket resteranno nel livello dei servizi, così le stesse regole si applicheranno qualunque sia la schermata che apre la finestra.

Crea una finestra di dialogo focalizzata per inserire un ticket e modificarne uno esistente. Fornire risultati distinti per Salva e Annulla in modo che la chiusura della finestra di dialogo non implichi mai silenziosamente che i dati siano stati accettati.

Raggruppa i campi del ticket all'interno della finestra di dialogo e mantieni Salva e Annulla facili da trovare. La finestra di dialogo dovrebbe raccogliere una modifica coerente, con informazioni sufficienti affinché l'utente possa esaminarla prima di accettarla.

Inizializza la stessa finestra di dialogo in modo diverso per ciascun flusso di lavoro. Il nuovo inizia con un input vuoto; Modifica carica il biglietto selezionato. Il riutilizzo del layout mantiene coerenti i due flussi di lavoro senza confondere i loro stati iniziali.

Esegui ValidateForm prima di restituire un risultato accettato. Se mancano i valori richiesti, mantenere aperta la finestra di dialogo. DialogResult.OK dovrebbe comunicare un input accettato valido, non semplicemente che è stato premuto il pulsante Salva.

Apri Nuovo e prova a salvare senza titolo. Il messaggio identifica le informazioni mancanti e la finestra di dialogo rimane aperta, offrendo all'utente la possibilità di correggere l'input senza riavviare l'operazione.

Completa i campi richiesti e accetta la finestra di dialogo. Il genitore quindi chiama TicketService e aggiorna la griglia. Segui tale ordine in modo che l'utente veda il risultato della modifica accettata e salvata.

Seleziona un biglietto esistente e apri Modifica. I suoi valori correnti dovrebbero apparire nella stessa finestra di dialogo. Modifica un campo, salva e verifica che la riga corrispondente venga aggiornata anziché creare un altro ticket.

Utilizza la stessa sequenza per entrambi i flussi di lavoro: convalida, accettazione, salvataggio tramite il servizio e aggiornamento. Mantenere queste fasi esplicite rende più semplice gestire gli errori di cancellazione e convalida senza scritture accidentali.

Eseguiremo un’esportazione o un’importazione simulata in background e ne mostreremo l’avanzamento senza bloccare l’interfaccia. Ogni utente connesso manterrà lo stato della propria operazione. Gestiremo anche gli errori con un messaggio utile per l’utente, senza mostrare nella schermata i dettagli interni dell’errore.

Utilizza la dimostrazione di esportazione e importazione per seguire un lavoro nel tempo. Uno schermo reattivo ha bisogno di più di una barra di avanzamento: gli utenti devono capire se il lavoro è in corso, terminato, annullato o fallito.

Mantieni visibili insieme i comandi di avvio, annullamento, avanzamento e registro. Rispondono a diverse domande: cosa posso fare, a che punto è il lavoro e cosa è già successo?

In RunJobAsync, attendi ogni passaggio e segnalane l'avanzamento. Utilizza il gestore errori per gli errori e il blocco finally per la pulizia, in modo che l'interfaccia possa lasciare lo stato occupato anche quando il lavoro fallisce.

Avvia l'importazione e osserva i controlli cambiare durante l'esecuzione del lavoro. Disabilita i comandi che potrebbero entrare in conflitto con l'operazione attiva, ma mantieni disponibili i progressi e il feedback in modo che l'utente possa seguire il lavoro.

Mantieni i progressi e altri valori specifici dell'utente nella sessione corrente. Un campo statico è condiviso tra gli utenti, quindi la memorizzazione dello stato lavorativo di una persona potrebbe far sì che un'altra persona lo veda o lo modifichi.

Abilita Simula errore ed esegui nuovamente il lavoro. Conserva i dettagli diagnostici nel registro per eventuali indagini, mentre l'utente riceve un breve messaggio sicuro. I dettagli tecnici dell'eccezione non dovrebbero diventare testo di errore pubblico.

Il pulsante avvia l'operazione, il lavoro esegue il lavoro e lo schermo ne segnala lo stato. Mantieni questi ruoli separati in modo che il successo, l'annullamento e il fallimento possano riportare l'interfaccia a una condizione utilizzabile.

Aggiorneremo l’aspetto della dashboard usando un tema integrato, schede e una navigazione coerente. I servizi, la validazione e il data binding esistenti continueranno a svolgere il proprio compito. Potremo così migliorare la leggibilità e la navigazione della schermata senza riscrivere il comportamento di business dell’applicazione.

Modernizza lo schermo esistente senza ricostruirne il comportamento. Un tema Wisej.NET fornisce scelte visive coerenti; I miglioramenti al layout e alla navigazione rendono l'applicazione più facile da comprendere.

Rendi il titolo della pagina facile da identificare, raggruppa le metriche correlate e posiziona i comandi accanto al contenuto che influisce. La gerarchia visiva dovrebbe aiutare gli utenti a decidere dove guardare e cosa fare dopo.

Il selettore del tema cambia Application.Theme.Name, mentre SetActiveButton contrassegna l'elemento di navigazione selezionato. Tratta l'aspetto e la posizione come preoccupazioni separate in modo che gli utenti sappiano ancora dove si trovano dopo aver cambiato tema.

Passa da un tema integrato all'altro e confronta gli stessi controlli. Il loro aspetto cambia mentre il flusso di lavoro rimane lo stesso. Controlla la leggibilità e gli stati attivi invece di giudicare il tema solo dai suoi colori.

Esamina la dashboard finita nel suo insieme. Spaziatura, schede e navigazione coerenti dovrebbero supportare l'associazione e la convalida dei dati esistenti. Un aggiornamento visivo ha esito positivo quando il flusso di lavoro familiare diventa più chiaro.

Aggiungeremo una piccola visualizzazione di stato JavaScript a una schermata Wisej.NET. I controlli nativi continueranno a gestire le interazioni ordinarie, mentre C# manterrà la responsabilità dei dati, delle decisioni e della registrazione degli eventi. Il widget mostrerà i valori ricevuti, offrendo una visualizzazione specializzata senza creare una seconda fonte dello stato dell’applicazione.

Aggiungi una piccola visualizzazione JavaScript all'applicazione Wisej.NET esistente. Mantenere la logica principale in C# in modo che l'elemento visivo aggiuntivo non diventi un secondo proprietario delle decisioni dell'applicazione.

Utilizza etichette, pulsanti e registrazioni Wisej.NET nativi per l'interazione ordinaria. Presentare uno Widget solo per il visual specializzato. Ciò mantiene l'integrazione focalizzata invece di sostituire i controlli che già risolvono il problema.

Invia al widget solo i valori visualizzati di cui ha bisogno: stato, conteggio dei ticket e carico del sistema. C# rimane responsabile di tali valori; la visualizzazione del browser li presenta senza ricevere dati del server non correlati.

Il gestore dei pulsanti aggiorna le etichette native e invia gli stessi dati tramite UpdateWidget. L'utilizzo di un risultato per entrambe le presentazioni impedisce al testo e alla visualizzazione di descrivere stati diversi.

Click Aggiorna i dati del server e confronta le etichette con il widget. Dovrebbero cambiare insieme dalla stessa operazione del server. Se non sono d'accordo, ispeziona i dati trasmessi oltre il confine di integrazione.

Prova a turno Salutare, Avvertenza e Critico. Gli eventi C# aggiornano lo stato visivo e registrano la modifica. La cronologia degli eventi aiuta a spiegare perché il widget ha l'aspetto attuale.

Controlleremo l’applicazione prima di preparare il pacchetto di rilascio. Configurazione, segreti, registrazione degli eventi e permessi richiedono ciascuno una verifica esplicita. Il processo di rilascio userà queste verifiche per decidere se il pacchetto è pronto, mantenendo i dettagli riservati fuori dai messaggi destinati agli utenti.

Utilizza la schermata di revisione per raccogliere prove prima del rilascio. I controlli di configurazione, sicurezza e distribuzione fanno parte di un unico processo ripetibile, quindi la preparazione dipende dai controlli completati piuttosto che da un'impressione rassicurante.

Registrare innanzitutto l'ambiente, la destinazione dell'hosting, la versione e il revisore. Questi dettagli identificano esattamente ciò che viene esaminato; una lista di controllo completata per un ambiente non copre automaticamente una destinazione di rilascio diversa.

Eseguire i controlli di configurazione richiesti separatamente dalle note facoltative. Una nota può spiegare un'eccezione, ma non dovrebbe far sparire un controllo richiesto mancante dalla decisione di disponibilità.

Mantieni i segreti e le eccezioni dettagliate fuori dalla visualizzazione della revisione. Mostra un riepilogo sicuro e lascia i dettagli diagnostici nei log del server, in modo che il pacchetto di revisione possa essere condiviso senza esporre le credenziali.

Prontezza separata dal permesso. I controlli richiesti determinano se la revisione è completa, mentre un controllo del ruolo determina chi può creare il pacchetto. Il superamento della checklist non concede all'utente ulteriore autorità.

Completa gli elementi rimanenti richiesti e osserva il conteggio raggiungere nove su nove. Lo stato cambia in Pronto per la revisione. Ciò significa che la lista di controllo è completa, non che la distribuzione sia già avvenuta.

Crea il pacchetto di revisione e controlla il suo riepilogo, inclusi i problemi noti e le informazioni di rollback. Un passaggio utile indica al revisore cosa è pronto, cosa rimane incerto e come ripristinare se il rilascio fallisce.

Modulo dieci. Costruisci il mini helpdesk Wisej.NET. Questa pietra miliare riunisce il corso in un'unica applicazione. Ne seguiremo la navigazione, il flusso di lavoro dei ticket e le schermate di supporto, quindi esamineremo ciò che rende il progetto pronto per la revisione e la distribuzione.

Inizia con l'applicazione completata e segui la sua shell di navigazione. Gli esempi di corsi separati ora condividono un layout, in modo che gli utenti possano spostarsi tra le funzionalità senza apprendere ogni volta un nuovo modello di navigazione.

Segui Ticket, Clienti e Lavori attraverso le loro principali interazioni. Le griglie presentano i record, le finestre di dialogo raccolgono le modifiche e i processi in background segnalano l'avanzamento. Dopo ogni azione, controlla che il risultato visibile spieghi cosa è realmente accaduto.

Tracciare una modifica del ticket attraverso le sue responsabilità. La finestra di dialogo convalida l'input, TicketService gestisce l'operazione e la griglia presenta il risultato. Etichette e messaggi di stato coerenti collegano queste fasi per l'utente.

Utilizza Deployment e Architettura per spiegare l'applicazione oltre le sue schermate. Esamina la configurazione, la sicurezza e la registrazione, quindi traccia i dati attraverso il livello di servizio. Una dimostrazione operativa dovrebbe anche rendere comprensibile la sua organizzazione.

Termina con la revisione del codice e i passaggi successivi. Controlla i nomi significativi e le responsabilità chiare, quindi registra il lavoro di produzione rimanente. La chiave di volta dimostra un'applicazione funzionante rendendo espliciti il ​​lavoro incompiuto e le decisioni di progettazione.