Spring MVC: gestione degli errori di convalida tramite AJAX

4

Sono nuovo di Spring MVC, quindi la domanda potrebbe sembrare banale.

Ho un modulo di accesso che viene inviato tramite Ajax e in cambio ricevo un ModelAndView (che mostra l'elenco esistente di contatti dell'utente) dal Controller, che utilizzo per sovrascrivere il contenuto esistente - il modulo di accesso esistente HTML in caso di successo. L'oggetto del mio modello contiene l'elenco degli errori di convalida che vengono popolati in caso di errori nel mio modulo.

Voglio mostrare gli errori di convalida nel mio modulo di accesso se ce ne sono. Come devo procedere per implementarlo - dovrei inviare un JSON invece di HTML dal server e costruire la pagina sul client usando i template jQuery - o questo può essere ottenuto anche se il Controller restituisce un ModelAndView?

Ho considerato di avere il JSP di login e i contatti JSP combinati in uno e nascondere / mostrare in base alla risposta. Non voglio farlo però, poiché questo aumenterebbe solo il carico utile da inviare al client.

Penso che questo sia un problema molto comune quindi ci dovrebbero già essere le migliori pratiche / approcci di progettazione per gestirlo.

    
posta Abhigyan Mehra 17.09.2016 - 16:53
fonte

2 risposte

1

Ha senso inviare solo JSON al client per una serie di motivi:

  1. Meno traffico tra client e server. Se convalidi un modulo complesso, devi indicare errori in più campi. Invece di inviare forme completamente renderizzate con questi campi hilighted, puoi inviare solo JSON con nomi di campi e suggerimenti di correzione (NB: dal punto di vista di UX, è meglio dire all'utente come correggere, non solo come è sbagliato).

  2. Evita il rendering della duplicazione del codice. Se disponi di una convalida sul lato client, avrai comunque il rendering lato client degli errori di convalida. Per rendere coerenti il comportamento e la presentazione delle applicazioni, è meglio avere tutto il codice di rendering in un'unica posizione e, a causa della convalida sul lato client, significa - sul client, non sul server.

Ci sono ancora casi in cui non è possibile avere il rendering dell'interfaccia utente lato client: quando l'utente ha disabilitato JavaScript o ha un software client non standard, per citarne alcuni. Il numero di tali utenti è molto basso e, considerando i vincoli delle risorse di sviluppo, potresti decidere di ignorare questo pubblico. In caso contrario, esiste un approccio comune (ora implementato in framework Angular2) per avere un fallback di rendering sul lato server, in cui si esegue sostanzialmente lo stesso codice di rendering sul server per restituire l'HTML statico al client. Il mio consiglio è di attenersi a una soluzione più semplice e poi, quando hai raggiunto altri obiettivi, pensa al fallback lato server.

    
risposta data 17.09.2016 - 18:55
fonte
0

should I send a JSON instead of HTML from the server and construct the page at the client using jQuery templates - or can this be achieved even if the Controller returns a ModelAndView?

No. Quello sarebbe reinventare la ruota. Esistono già quadri per lavorare in questo modo. Sebbene, in qualche modo incompatibile con il tipo di applicazione proposto da Spring MVC.

Spring MVC non è stato progettato per essere implementato in questo modo.

I have considered having the login JSP and the contacts JSP combined into one and hide/unhide based on response

Dal punto di vista del design front-end, è una pessima idea. Ancora una volta, stai cercando di risolvere qualcosa che è già stato risolto da altri framework. E cercando di sconfiggere il design dell'applicazione proposto da Spring MVC.

Il problema principale che vedo qui è che hai abusato del framework.

Le applicazioni Spring MVC rientrano nel gruppo di applicazioni Web in cui il server controlla lo stato di entrambe le applicazioni, server e client.

In breve, il client è "compilato" (generato) dal server e fornito al client nel suo stato finale. Il browser visualizza semplicemente il contenuto così com'è e attende l'interazione dell'utente.

Per Spring MVC per controllare lo stato dell'intera applicazione, è necessario inviare richieste al server, in modo che il server calcoli il nuovo stato e restituisca la rappresentazione (principalmente la vista come documento html) al browser.

Questo si applica anche alla navigazione. Ogni volta che navighiamo, cambiamo lo stato dell'applicazione, quindi la richiesta e la pagina si ricaricano.

Detto questo, e tornando alla domanda, la tua implementazione sta sconfiggendo il design sopra, quindi la complessità in quasi tutto ciò che provi a fare.

Nelle applicazioni MVC di Spring, JQuery e AJAX svolgono un ruolo diverso. Sono usati per fornire la vista con un certo grado di dinamismo; Ad esempio, aggiornare piccole sezioni della pagina. Pensa alle paginazioni, alle liste dinamiche e alle combo, alle ricerche, agli effetti visivi, ai processi in background, ecc. Funzionalità che farebbero riscrivere il server e aggiornare l'intera pagina solo per piccole (o impercettibili) modifiche. Come puoi immaginare, è abbastanza inefficiente. E noioso, dal punto di vista dell'esperienza utente.

I think this is a very common problem so there should already be best practices/design approaches for handling this.

Sì, erano 10-15 anni fa; quando AJAX e JQuery (più tardi), hanno rivoluzionato il mercato delle applicazioni web. Questi due hanno causato una sorta di nevrosi che ha portato molte persone a sviluppare applicazioni web esilaranti. Tieni presente che le librerie e i browser JavaScript non erano così sofisticati come al momento.

Fortunatamente, queste tecnologie si sono evolute in base alle tendenze e alle esigenze del mercato. Più o meno, verso consentire i client web disaccoppiati.

Riassumendo, suggerirei due possibili soluzioni:

  1. Continua ad implementare Spring MVC, ma smetti di usare JQuery e AJAX come lo stai facendo ora. Supponiamo che JQuery non debba fare sul lato client cosa dovrebbe essere fatto da Spring sul lato server.

  2. Modifica Spring MVC di Spring Web. Sostituisci @Controllers con @RestControllers, estrai le viste dal server, rendi il server stateless e implementa il front-end in modo indipendente dal back-end.

Indipendentemente dalle opzioni di cui sopra, ciò che conta è fare un uso corretto degli strumenti. O in altre parole, per scegliere lo strumento giusto per ogni problema.

    
risposta data 16.09.2017 - 00:50
fonte

Leggi altre domande sui tag