4

I'm new to Spring MVC, hence the question may appear trivial.

I have a login form which is submitted via ajax and in return I receive a ModelAndView (displaying existing list of contacts of the user) from the Controller, which I use to overwrite the existing content - the existing login form HTML upon success. My model object contains the list of validation errors which gets populated if there were errors in my form.

I want to show validation errors in my login form if there are any. How should I go about implementing it - 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?

I have considered having the login JSP and the contacts JSP combined into one and hide/unhide based on response. I do not want to do this though, as this would only increase the payload to be sent to the client.

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

Abhigyan Mehra
  • 201
  • 1
  • 2
  • 5

2 Answers2

1

It does make sense to send only JSON to client for a number of reasons:

  1. Less traffic between client and server. If you validate some complex form, you'll need to indicate errors in multiple fields. Instead of sending completely rendered form with these fields hilighted, you can send only JSON with names of fields and fix suggestions (NB: from UX perspective, it's better to tell user how to fix, not just how he is wrong).

  2. Avoid rendering code duplication. If you have anywhere client-side validation, you'll have the client-side rendering of validation errors anyway. To make your application behavior and presentation consistent, it's better if you'll have all rendering code in one place, and because of client-side validation it means - on the client, not on the server.

There are still cases, when you cannot have client-side rendering of UI: when user has disabled JavaScript or has non-standard client software, to name few. The number of such users is very low and, considering your development resource constraints, you may decide to ignore this audience. If you do not, there's common approach (now implemented in Angular2 framework) to have a server-side rendering fallback, where you execute basically the same rendering code on server to return static HTML to client. My advice is to stick to simpler solution and then, when you achieved other goals, think about server-side fallback.

Ivan Gammel
  • 1,226
  • 10
  • 12
  • Thanks Ivan, but this didn't quite answer my question - which was if I send a JSON response to the client, how do I display the server rendered JSP. The solution I came up with was to wrap the HTML inside JSON - using the ViewResolver that Spring provides alongwith MockHttpServletResponse (http://stackoverflow.com/questions/22422411/how-to-manually-render-spring-mvc-view-to-html) – Abhigyan Mehra Sep 24 '16 at 18:59
  • 1
    @AbhigyanMehra as I can see you did not mention in your question about displaying server-rendered JSP while sending JSON at the same time. As I already said, it makes sense to send JSON only - that is, without HTML, to client and then do the rendering on client. Sending HTML wrapped in JSON is bad idea for the same reasons I've mentioned in my answer. – Ivan Gammel Sep 25 '16 at 16:51
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. That would be reinventing the wheel. There are already frameworks for working in this way. Although, somewhat incompatible with the kind of application that Spring MVC proposes.

Spring MVC was not designed to be implemented in this way.

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

From the front-end design point of view, that's a terrible idea. One more time, you are trying to solve something that has been already solved by other frameworks. And trying to defeat the application design proposed by Spring MVC.

The main problem I see here is that you have misused the framework.

Spring MVC applications fall into the group of web applications in which the server controls the state of both applications, server and client.

Briefly summarized, client is "compiled" (generated) by the server and supplied to the client in its final state. The browser just render the content as it's and wait for the user interaction.

For Spring MVC to control the state of the whole application, it's required to send requests to the server, so that the server calculates the new state and return the representantion (mainly the view as a html document) back to the browser.

This is applied to the navigation too. Every time we navigate, we change the state of the application, hence the request and the page reload.

That said, and back to the question, your implementation is defeating the above design, hence the complexity in almost everything you try to do.

In Spring MVC applications, JQuery and AJAX play a different role. They are used to provide the view with some degree of dynamism; e.g updating small sections of the page. Think in paginations, dynamic lists and combos, look ups, visual effects, background processes, etc. Features that would cause the server to rewrite and refresh the whole page just for so little (or unnoticeable) changes. As you guess, that's quite ineficient. And tedious, from the user experience standpoint.

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

Yes, it was 10-15 years ago; when AJAX and JQuery (later), revolutionized the market of web applications. These two caused a sort of neurosis that led many people to develop hilarious web applications. Keep in mind that JavaScript libraries (and browsers) were not so sophisticated as they are these days.

Fortunately, these technologies have evolved according with the trends and the needs of the market. More or less, towards to allowing decoupled web clients.

Summarising, I would suggest two possible solutions:

  1. Keep implementing Spring MVC, but stop using JQuery and AJAX as you are doing it now. Assume that JQuery should not to do in the client side what should be done by Spring in the server side.

  2. Change Spring MVC by Spring Web. Replace @Controllers by @RestControllers, take views out of the server, make the server statless and implement the front-end independently from the back-end.

Regardless the above options, what matters is to make a proper usage of the tools. Or in other words, to choose the right tool for each problem.

Laiv
  • 14,283
  • 1
  • 31
  • 69