Corso di integrazione applicativa

Segui un'integrazione tra server e browser. Wisej.NET possiede lo stato del componente, mentre un widget del browser lo presenta. Mantenere esplicito questo confine impedisce alla libreria del fornitore di diventare il livello aziendale dell’applicazione.

Distinguere il componente dal suo widget. Il componente possiede lo stato dell'applicazione; il widget gestisce il comportamento del browser. Gli eventi li collegano segnalando modifiche significative, anziché copiare ogni interazione del browser sul server.

Traccia i dati verso l'esterno come JSON compatto, quindi nelle opzioni del fornitore. Traccia gli eventi importanti sul server. Questo limite dell'adattatore consente al codice server di funzionare con un contratto stabile anziché con dettagli specifici del fornitore.

Ispezionare TemperatureGauge nel designer. Value è la proprietà modificata dall'applicazione; ThresholdExceeded è l'evento che gestisce. L'indicatore del fornitore rimane all'interno di questa familiare interfaccia del componente Wisej.NET.

Guarda il server cambiare Value e l'indicatore lo esegue il rendering. Alla soglia visualizzata, ritorna un evento con informazioni utili. L'applicazione risponde al superamento della soglia, non a ogni fotogramma di animazione visiva.

Classificare il misuratore, l'editor e la griglia prima di scrivere il codice di integrazione. Le loro esigenze in termini di risorse, dati ed eventi differiscono. Confrontare innanzitutto tali esigenze aiuta a scegliere una superficie di integrazione sufficiente senza inutili complessità.

Scrivi un documento decisionale sull'architettura che spieghi la tua scelta. Includere vincoli di riutilizzo, tematizzazione, sicurezza e manutenzione. Il punto è preservare il ragionamento, in modo che un altro sviluppatore possa giudicare se la scelta sia ancora adatta in seguito.

Invia insieme il diagramma, la tabella di confronto e il record della decisione. Dovrebbero raccontare una storia coerente: dove vive lo stato, come comunica il widget e perché l'approccio di integrazione selezionato soddisfa i suoi requisiti.

Ora disponi di un progetto di integrazione che qualcun altro può rivedere. Utilizza questa comprensione condivisa come punto di partenza per l'implementazione e i test, invece di considerare un'immagine funzionante come l'intera integrazione.

Verifica il comportamento JavaScript prima di integrarlo in Wisej.NET. Un piccolo esempio isolato aiuta a distinguere un errore nella libreria o nell'uso del linguaggio da un problema introdotto dall’integrazione.

Nel callback della libreria, controlla a quale oggetto si riferisce this. Potrebbe essere l’oggetto della libreria, che non dispone del metodo fireWidgetEvent. Il metodo manca perché l’oggetto su cui lo stai chiamando è sbagliato, non perché Wisej.NET abbia perso l’evento.

Mantieni un riferimento esplicito al widget in una closure, associa il callback all’istanza corretta oppure chiama un metodo del widget. Ciascuna soluzione permette al callback di raggiungere in modo affidabile l’istanza corretta quando la libreria lo richiama.

Dichiara le dipendenze nell’ordine richiesto: libreria di supporto, stili, script della libreria esterna e infine inizializzazione. Packages rende esplicito quest’ordine, impedendo che l’inizializzazione parta prima che siano disponibili le risorse necessarie.

Sposta l’inizializzazione già verificata nell’InitScript del Widget e dichiara le risorse in Packages. Mantieni le stesse dipendenze e lo stesso ordine dell’esempio isolato, in modo che l’integrazione non cambi implicitamente il modo in cui la libreria si avvia.

Usa gli strumenti per sviluppatori del browser per esaminare l’istanza memorizzata della libreria e seguire valueChanged. sourceURL assegna al codice inserito un nome riconoscibile; un’istruzione debugger permette di interrompere l’esecuzione nel punto in cui viene effettivamente eseguito il callback.

Conserva insieme l’esempio isolato, l’InitScript funzionante e le note di debug. Un eventuale errore futuro potrà così essere riprodotto fuori dall’integrazione e confrontato con la configurazione effettiva del widget.

L’integrazione ha ora un punto di partenza verificato, dipendenze esplicite e un contesto affidabile per i callback. Queste basi facilitano il debug del successivo codice del wrapper, perché il comportamento JavaScript di base è già stato compreso.

Inizia con uno Widget per dimostrare rapidamente l'integrazione. Ciò dà alla libreria del fornitore un posto all'interno di Wisej.NET prima di investire in un controllo riutilizzabile con un'interfaccia pubblica più ampia.

Posiziona lo Widget sul cruscotto e mantieni il primo esempio piccolo. La domanda immediata è se le risorse vengono caricate e l'oggetto del fornitore può essere eseguito nel suo contenitore, non se l'astrazione è terminata.

Assegna lavori separati a Packages, Options e InitScript. Packages carica le dipendenze, Options trasporta i dati correnti e InitScript crea l'oggetto visivo. Mantenere chiari questi ruoli rende più facile diagnosticare un'integrazione fallita.

Crea l'istanza del fornitore durante l'inizializzazione, quindi aggiorna l'istanza esistente quando le opzioni cambiano. Ricrearlo a ogni aggiornamento può duplicare i gestori o perdere lo stato che appartiene al widget corrente.

Utilizza il pulsante del server per modificare Options e guarda l'aggiornamento per aggiornare l'immagine. Una chiamata in coda gestisce un comando imperativo. Distinguere la modifica dello stato del widget persistente dalla richiesta di un'azione client una tantum.

Invia insieme le dichiarazioni delle risorse, l'inizializzazione, la logica di aggiornamento e l'interazione del server. Dovrebbero dimostrare sia la prima creazione che le modifiche successive. Il riutilizzo su più schermi è il motivo successivo per introdurre un wrapper.

Il prototipo ha ora stabilito che la libreria può caricare, eseguire il rendering e rispondere all'interno di Wisej.NET. Trasporta questi comportamenti comprovati in un involucro riutilizzabile invece di copiare il prototipo su ogni pagina.

Sposta la configurazione ripetuta del widget in una classe riutilizzabile. Quando i percorsi delle risorse o l'inizializzazione cambiano, un'implementazione mantenuta dovrebbe servire ogni schermata invece di richiedere modifiche a diversi script copiati.

Lascia che SimpleGauge erediti il comportamento Wisej.NET Widget e possieda i suoi Packages, Options e InitScript. La pagina dovrebbe richiedere il comportamento del misuratore attraverso la classe, senza sapere come è assemblata la libreria del fornitore.

Esporre Value, Minimum, Maximum e Caption come proprietà digitate. Le descrizioni e le categorie aiutano l'utente progettista a scegliere impostazioni valide, mentre il wrapper traduce internamente tali impostazioni nelle opzioni del fornitore.

Mantieni pubbliche le proprietà supportate e nascondi i dettagli di implementazione ove appropriato. Se i chiamanti possono sostituire liberamente l'inizializzazione o le opzioni grezze, possono ignorare le garanzie che rendono affidabile il wrapper.

Posiziona la classe in una pagina dimostrativa e modificala tramite le normali proprietà. L'assenza di InitScript specifico per la pagina è una prova utile: la conoscenza dell'integrazione vive davvero all'interno della classe riutilizzabile.

Fornisci la classe con proprietà documentate, impostazioni predefinite e una pagina di esempio pulita. Un revisore dovrebbe essere in grado di crearne un'istanza e comprendere le impostazioni supportate senza aprire lo script di inizializzazione del fornitore.

Un buon involucro rende il normale funzionamento semplice e difficile l'uso improprio accidentale. Valuta l'interfaccia pubblica dal punto di vista dell'autore della pagina, non solo dal punto di vista della persona che ha creato l'integrazione.

Crea un controllo personalizzato quando l'integrazione deve comportarsi come parte dello stesso Wisej.NET. L'obiettivo è un componente riutilizzabile che partecipi al comportamento e ai temi in fase di progettazione, non solo a un oggetto visivo ospitato.

Confronta un wrapper Widget con uno Control a livello di piattaforma. Scegliere l’integrazione più forte quando il comportamento nativo e la partecipazione al tema la giustificano; il lavoro di implementazione aggiuntivo dovrebbe rispondere a un reale requisito di riutilizzo.

Accoppiare il server SimpleGaugeControl con la sua classe client in Platform. Le due classi hanno responsabilità diverse: il server espone lo stato dell'applicazione, mentre il client implementa il modo in cui tale stato appare e si comporta nel browser.

Utilizzare OnWebRender per creare una configurazione client deliberata. Includere le proprietà necessarie per eseguire il rendering dell'indicatore, anziché serializzare oggetti server non correlati. È più facile ragionare e mantenere un piccolo confine esplicito.

Collega la chiave dell'aspetto alla definizione del tema. Ciò consente al tema di controllare le scelte visive invece di codificare un aspetto separato in ogni schermata che utilizza il controllo.

Esamina il controllo nella finestra di progettazione e prova le dimensioni e le impostazioni del tema. Il rendering in fase di progettazione fa parte dell'integrazione: altri sviluppatori devono organizzare il controllo senza prima eseguire l'intera applicazione.

Inviare entrambe le classi, la voce relativa all'aspetto e le prove in fase di progettazione. Insieme dimostrano il percorso completo dalla proprietà del server a un controllo a tema che un altro sviluppatore può posizionare visivamente.

Guarda diverse istanze che condividono la stessa implementazione del controllo sulla dashboard. I loro valori variano, ma il loro comportamento e l’integrazione dei temi rimangono coerenti. Questa coerenza è il vantaggio di incapsulare l'integrazione una volta.

Decidi se ogni interazione invia un comando o necessita di un risultato. Questa distinzione determina come continua il codice del server, quali dati oltrepassano il confine e se devono attendere una risposta del browser.

Utilizza Chiama quando il browser deve eseguire un'azione e non è necessario alcun valore restituito. Il comando è in coda, quindi il codice server successivo non deve presupporre che il browser abbia già finito di eseguirlo.

Utilizza CallAsync o EvalAsync quando il passaggio successivo dipende dal risultato del browser. Attendere l'operazione prima di utilizzare il risultato, in modo che il flusso di lavoro segua la risposta invece di correre avanti con i dati mancanti.

Definire un piccolo oggetto di trasferimento dati e controllarne i nomi delle proprietà serializzate. Il browser riceve il contratto serializzato, non l'oggetto C# originale. I campi espliciti evitano di esporre stati non correlati e riducono le mancate corrispondenze dei nomi.

Confronta le operazioni dal vivo: un comando cambia l'indicatore, una chiamata attesa ne legge le dimensioni renderizzate e un oggetto compatto restituisce lo stato di selezione. Ogni scambio porta solo ciò che richiede quella particolare interazione.

Fornire esempi di comandi unidirezionali e risultati attesi, oltre al contratto sui dati di ritorno. Un revisore dovrebbe essere in grado di identificare dove attende l'esecuzione e quali campi il browser può restituire.

Mantieni il confine organizzato attorno a comandi, risultati e contratti dati espliciti. Ciò rende visibili i tempi e la responsabilità, il che è più affidabile che trattare il codice del browser come un’estensione sincrona del server.

Tratta i callback dei fornitori come input grezzi per l'integrazione. L'applicazione necessita di un insieme stabile di eventi significativi, quindi l'adattatore deve decidere cosa inoltrare anziché esporre direttamente ogni notifica del fornitore.

Separare l'attività visiva dalle decisioni applicative. Il movimento o l'animazione del puntatore possono rimanere locali, mentre una selezione significativa o un cambiamento di stato potrebbero richiedere il server. Il filtraggio a questo confine evita il traffico non necessario e il lavoro del gestore.

Registrare il callback del fornitore una volta durante l'inizializzazione e inoltrare un evento con nome compatto. Registrarlo nuovamente a ogni aggiornamento può far sì che un'azione dell'utente attivi più gestori di server in modo imprevisto.

Utilizza il percorso dell'evento che corrisponde alla superficie di integrazione. Widget inoltrati tramite fireWidgetEvent e WidgetEvent; i controlli personalizzati utilizzano gli eventi client e OnWebEvent. Mescolare i percorsi invia i dati al meccanismo di gestione sbagliato.

Definire il nome di ciascun evento e il payload prima di collegare i gestori. I superamenti delle soglie, le modifiche dei valori e le selezioni dei punti richiedono informazioni diverse. Piccoli contratti espliciti chiariscono su cosa può fare affidamento un gestore di server.

Interagisci con l'indicatore, la manopola e il grafico e segui gli eventi che raggiungono il server. Controlla che ciascun payload contenga i valori rilevanti e che l'attività visiva locale non sia diventata un flusso di messaggi del server non necessari.

Invia gestori client e server accoppiati con la tabella dei contratti. Un revisore dovrebbe essere in grado di tracciare ogni evento dal trigger del browser alla decisione del server, incluso esattamente quali dati oltrepassano il limite.

Alcuni widget dei fornitori recuperano i propri dati anziché ricevere tutto tramite Options. Assegna a tali richieste un endpoint esplicito e preserva il contesto del componente corretto, in modo che la risposta appartenga all'utente e al widget previsti.

Utilizza getPostbackUrl quando un widget prevede un indirizzo dati. Instrada la richiesta alla sessione e all'istanza del componente appropriate. L'indirizzo fornisce il contesto, ma il gestore deve comunque convalidare l'operazione richiesta.

In WebRequest, verificare l'azione richiesta prima di produrre dati. Imposta il tipo di contenuto JSON e scrivi la forma di risposta prevista. Una risposta di trasporto valida non è sufficiente se il widget non è in grado di interpretarne il contenuto.

Utilizzare WebMethod per un'operazione digitata che il codice cliente chiama direttamente. Gli argomenti e il valore restituito formano il contratto, quindi il chiamante può attendere un risultato invece di gestire una richiesta di dati di proprietà del widget.

Scegli lo stile dell'endpoint in base a chi avvia e controlla la richiesta. Un'origine dati del fornitore utilizza naturalmente il proprio indirizzo; il codice dell'applicazione che chiama un'operazione denominata beneficia di un metodo tipizzato e di un risultato esplicito.

Segui la richiesta della griglia al gestore del postback e torna alle righe sottoposte a rendering. Controllare la struttura della risposta a quel confine; una griglia vuota può indicare una mancata corrispondenza del contratto anche quando la richiesta stessa ha avuto esito positivo.

Fornisci esempi di endpoint e spiega i chiamanti previsti. Esaminare l'autorizzazione e la convalida dell'input per ciascun percorso. La scelta di un meccanismo endpoint conveniente non rimuove mai la responsabilità del server di proteggere l’operazione.

Utilizza gli esempi di griglia e pivot per identificare il modello di integrazione sotto la sintassi specifica del fornitore. L'applicazione necessita comunque del caricamento delle risorse, delle operazioni sui dati, degli eventi e di un'interfaccia Wisej.NET stabile indipendentemente dalla libreria scelta.

Assegnare all'adattatore la proprietà della creazione, delle opzioni, degli eventi e dell'accesso ai dati. Mantenere insieme questi dettagli rivolti al fornitore impedisce alle singole pagine di sviluppare versioni incompatibili della stessa integrazione.

Confronta DataSource e CustomStore in base alle operazioni richieste, non solo alla loro sintassi. Entrambi necessitano di un percorso per caricare e modificare i dati; l'adattatore traduce i loro argomenti nel contratto del tuo server.

Definire il paging, l'ordinamento e il filtro in GridOperationRequest prima di implementare i gestori. Convalidare tali input sul server, quindi mapparli all'operazione supportata. Le istruzioni di query fornite dal browser sono ancora input non attendibili.

Specificare payload separati per gli eventi di modifica delle righe, inserimento, eliminazione e selezione. Ciascuno dovrebbe identificare l'operazione prevista e i valori necessari, senza inviare un intero componente o esporre lo stato del server non correlato.

Segui il paging, l'ordinamento e la modifica attraverso lo stesso contratto del server mentre il pivot carica i suoi dati. Il confine comune mantiene comprensibili le operazioni dell'applicazione anche quando i widget del browser utilizzano interfacce di fornitori diversi.

Invia il contratto operativo, i gestori, i payload degli eventi e il piano pivot come un unico progetto coerente. Un revisore dovrebbe essere in grado di connettere ogni azione sui dati visibili a un'operazione del server esplicita e convalidata.

Esaminare l'integrazione come qualcosa che deve sopravvivere all'uso e all'implementazione ripetuti. Un primo rendering riuscito dimostra solo un percorso; la disponibilità della produzione dipende anche dalla gestione degli errori, dagli aggiornamenti, dalla pulizia e dai contratti mantenibili.

Esamina i percorsi delle risorse, il volume degli eventi, la pulizia del ciclo di vita, le tempistiche e le dimensioni realistiche dei dati. Queste preoccupazioni possono rimanere nascoste in una piccola dimostrazione, per poi diventare un fallimento quando lo stesso widget viene riutilizzato o distribuito altrove.

Name ha inserito script con sourceURL e fallisce chiaramente quando mancano i prerequisiti. Confronta l'esempio del fornitore isolato con la versione integrata. Ciò ti fornisce prove su dove inizia il fallimento invece di fare affidamento su congetture.

Aggiorna l'istanza del fornitore esistente e distruggila quando il controllo viene eliminato. Cicli di creazione e chiusura ripetuti non dovrebbero lasciare in vita gestori o oggetti dopo che il loro schermo è scomparso.

Avvia l’elaborazione in background tramite Application.StartTask. Quando il risultato è pronto, aggiorna il client e chiama Application.Update. Il flusso di lavoro non è completo finché il browser non può effettivamente visualizzare il nuovo stato del server.

Integra un widget sconosciuto utilizzando gli stessi limiti: un wrapper riutilizzabile, comandi del server, un evento significativo e un endpoint di dati protetto. L’esercizio verifica se puoi trasferire lo schema oltre gli esempi del corso.

Esamina la dashboard come diverse integrazioni che lavorano insieme. Traccia eventi, chiamate, caricamento e smaltimento per ciascun widget. Lo spazio visivo condiviso non dovrebbe offuscare quale wrapper possiede ciascuna risorsa e interazione.

Termina con un wrapper che un altro sviluppatore possa comprendere, testare e riutilizzare. Spiegarne il contratto pubblico e il ciclo di vita, compreso il comportamento in caso di fallimento. Il risultato duraturo è un’integrazione sostenibile, non semplicemente una dimostrazione impressionante.