NLJUG – Nederlandse Java User Group NLJUG – de Nederlandse Java User Group – is opgericht in 2003. De NLJUG verenigt software ontwikkelaars, architecten, ICT managers, studenten, new media developers en haar businesspartners met algemene interesse in alle aspecten van Java Technology.
Our first NLJUG JCP meeting was held on June 9th, 2016, and the subject of this event was the JSR 371 specification (“MVC 1.0”), which is to be included in Java EE 8.
The programme for the evening was as follows:
- An introduction into the specification was given (see http://www.slideshare.net/mauricedechateau/intro-into-mvc-10 for the slides)
- After a short dinner break, the participants got some hands-on experience in a workshop with MVC 1.0. We reused a lot of the materials that the Bulgarian JUG made available, a big ‘thank you’ for that!
- Finally we had a Q&A session on Hangouts with Ivar Grimstad, who most kindly made time for us in his busy Devoxx UK schedule. He also gave us a great demo of the latest implementation and tooling in Netbeans.
One of the most important evaluations we came to, is that we should have planned more time (than roughly one hour) for the hands-on part. Most participants didn’t get much further than setting up their environment and run the most basic examples. This unfortunately led to very little feedback on the subjects of the reference implementation and expected use. We did get a good look at the documentation, however, and had plenty of discussions based on that.
We have collected the questions and remarks, ranging from trivial typos to questioning some fundamental choices, and their responses on the users’ mailing list, below:
Questions and remarks on the specification
Overall:
| Q: What is the use of this approach? Isn’t server-side rendering becoming obsolete rapidly, in the era of SPAs built with JavaScript frameworks that communicate over ‘regular’ REST APIs with the backend? |
| A (from Arjan Tijms): The answer to this is quite long really, but the short of it is that by far not all sites are using SPA, and server side generation of HTML that can be rendered right away in one go has distinct advantages, particular with respect to energy efficiency on the client, initial time to display a page, and seo.
What’s “popular” changes all the time and specifically server and client side has risen and fallen in popularity many times before. A (from Florian Hirsch): I don’t think that the current SPA trend will last for long and it makes sense to be prepared when the trend goes back to the server 😉 Java EE has a great framework for building RESTful services but if you want to build a RESTful website you don’t get too much support. I think there’s definitely a need for a such a framework. A (from Christian Kaltepoth): I absolutely agree that server-side rendered web frameworks have quite some advantages over the SPA approach. |
| Q: If Facelets is a mandatory supported view engine, why are all the examples in the specification done with JSPs? |
| A (from Florian Hirsch): Do you mean in the specification PDF or the Ozark examples? In the PDF there are only two view examples at all (ch 2.3 Views and ch 4.2 CSRF). Would it help if we add a Facelets example to ch 2.3? I think it won’t differ too much from the JSP hello world.
I definitely agree that we need more examples like the javaee7-samples and more documentation. A (from Christian Kaltepoth): I agree with Florian that we should provide more sample applications. That will help people to get started. |
| From this remark a discussion was started (see https://java.net/projects/mvc-spec/lists/users/archive/2016-07/message/5) which will undoubtedly lead to additions to the specification that will aid users in the usage of MVC with Facelets. |
Section 2.1 Controllers:
| Q: Why allow hybrid classes, containing both JAX-RS resource methods and MVC controller methods? That leads to implementations that go against best practices, like separation of concerns. |
| A (from Ivar Grimstad): The specification simply allows for flexibility in this area. It is the responsibility of the application developers not to violate such best practices.
A (from Florian Hirsch): If you have a JAX-RS resource which returns a list of customers you can easily return them as JSON, XML or plain text depending on the Accept header of the client. If the client requests text/html you need to render HTML which is more than a data representation and can’t be easily done by a JAX-RS MessageBodyWriter. MVC will fill this gap. I would not like it to use two classes for the same resource just to support different Content Types. A (from Christian Kaltepoth): I actually like being able to combine all the server side code related to a single page in a single class which handles the HTML rendering AND the ajax requests. Of cause this only makes sense if the class doesn’t get too big. For more complex use cases splitting the code into MVC controllers and JAX-RS resources (for ajax stuff) definitely makes sense. A (from Ivar Grimstad): Agree. It is all about flexibility. The specification should not dictate how application developers should structure their apps. Whether it is a good idea or not to have hybrid controllers are up to the users of the API. |
| Q: In the Javadoc for Object.toString() it is stated:
“[…] In general, the toString method returns a string that “textually represents” this object. The result should be a concise but informative representation that is easy for a person to read. […]” Isn’t (ab)using the toString method for ‘other Java types’ to get a view path a violation of this contract? |
A (from Ivar Grimstad): The reasoning behind this is that it allows for the following:
A (from Florian Hirsch): The idea was to allow to use enums for view names. An example can be found in the mvc-toolbox:https://github.com/mvc-toolbox/mvc-toolbox/wiki/Type-safe-Views Would it help if we add more explanation why toString is used? A (from Christian Kaltepoth): It is interesting that you are mentioning this. Especially because I got similar feedback in the past. The reason for this was to allow a bit more flexibility as it provides a simple way to add support for other types returned from the controller (like the enums Florian mentioned). Actually we have only two choices. Either the spec mandates that the MVC implementation will throw an exception if some other type is returned from a controller or we try to handle other types gracefully which even provides a very simple way of extending the return type processing. BTW: JSF does it the same way. The specification states that toString() is called on the result returned from an action method. But actually everyone just returns a string and only a few people know that the spec supports other return types. |
Q: The need for the @View annotation is called into question:
|
| A (from Christian Kaltepoth): The reason for this is that in many cases a controller is responsible for rendering just a single view. So without something like @View you would have to spread the view name all over the controller for the return statements and/or define constants for the view name. |
| Q: Are there restrictions to how long objects with @RedirectScope should be kept around (by the CDI implementation)? Waiting indefinitely for GET requests that are never performed may lead to memory issues for large numbers of requests. |
| A (from Arjan Tijms): Only the last 25 are kept, so yes there are restrictions 😉 |
Section 2.2 Models:
| Q: Doesn’t the encouragement to developers to use CDI-based models, for which the support is only optional, possibly lead to unportable code/applications? Or is the ‘optional’ support restricted to just the view engines? That’s not quite clear from the text. |
| A (from Florian Hirsch): Would “Application developers are encouraged to use CDI-based models whenever supported **by the view engine**, and thus take advantage of the existing CDI and EL integration on the platform.” help?
A (from Christian Kaltepoth): +1 for changing the sentence like suggested! A (from Ivar Grimstad): +1 |
| A pull request was opened containing this text change: https://github.com/mvc-spec/mvc-spec/pull/10 |
Section 3.2 Validation Exceptions:
| Q: Since this is a mechanism for handling exceptions that occur during the binding and validation of input parameters, and parameters are handled in the exact same way as in JAX-RS, why wasn’t this feature added to JAX-RS instead, so it would be available there as well? |
| A (from Florian Hirsch): Valid question. Anyone else missing this feature in JAX-RS?
A (from Christian Kaltepoth): I think most JAX-RS applications use exception mappers for reporting errors to the user. The special case for MVC is basically that web applications typically need to render just a standard response (which is the HTML page) in this case. In JAX-RS you will actually never want to send a 200 status code with the standard response in case of invalid input parameters. But that’s just my view. Anyone else has a different opinion? A (from Ivar Grimstad): I agree, the fine grained control does not make much sense for JAX-RS. A (from Florian Hirsch): When a constraint violation occurs you have to decide how to proceed: show the form again with error messages, redirect to another page where missing data can be created, redirect to an error page etc. With JAX-RS you return the constraint violations to the client and he decides how to proceed. That’s why it’s usually enough to have one place for mapping constraint violations to a format the client can read. For MVC this does not work as we are the client and how a violated @NotNull should be handled varies. However there may be use cases where you also want more control in JAX-RS: Wouldn’t it be nice to additionally return a link where a user can create a billing address instead of just the message “billing address must not be null”? |
Chapter 4 Security:
| Q: With the same reasoning as for exceptions above, both attacks described here may target JAX-RS endpoints as well. So should these counter-measures not be implemented there as well? |
| A (from Florian Hirsch): XSS should IMHO be handled by escaping user input in the view so this should not target JAX-RS too much. I agree for CSRF but don’t see too much chance to add this to the next JAX-RS release. Other thoughts?
A (from Christian Kaltepoth): I agree that escaping characters is typically performed by the corresponding MessageBodyWriter. Not sure about the CSRF case to be honest. A (from Ivar Grimstad): Not sure about CSRF for JAX-RS either. If someone could come up with a nice example where it makes sense, it would be welcome. A (from Florian Hirsch): Here’s an explanation when a JSON WebService can be prone to CSRF attacks:http://stackoverflow.com/a/11024387/1353722 |
Section 5.1 Observers:
| Q: Isn’t it possible to take advantage of the asynchronous capabilities of JAX-RS, to prevent the drawbacks of the synchronicity of CDI events? |
| A (from Christian Kaltepoth): CDI 2.0 will support async event processing. So this shouldn’t be a problem. |
Section 7.2 Selection Algorithm:
| Q: It is stated that “Every possible return type from a controller method is either a Viewable or can be turned into one by calling a constructor.”. How does this hold for controllers returning void, as at least a String is needed? |
| A (from Ivar Grimstad): In section 2.1, the spec states for the controller return types: “void A controller method that returns void is REQUIRED to be decorated by @View“. If a controller is decorated with @View it returns a Viewable, which is a valid return type. I agree that the spec could be a little clearer on this point, so I will create a Jira issue to clarify it. |
| The JIRA issue mentioned in the answer can be found here: https://java.net/jira/browse/MVC_SPEC-66 |
Typos
| Section 2.2 Models | In the second paragraph: “Since we intent to show…” should be “Since we intend to show…”. |
| Section 3.3 Binding Exceptions | “… a 500 error code returned the client.” should be “… a 500 error code returned to the client.”. |
| Section 7.1 Introduction | “… calling its support method, …” should be “calling its supports method, …”. |
| Javadoc for javax.mvc.security.Csrf | “… accessible from EL via the MvcContext class as mvc.encoders.” should be “… accessible from EL via the MvcContext class as mvc.csrf.” |
All typos mentioned above were fixed in commit https://github.com/mvc-spec/mvc-spec/commit/26e784e16c2a852ed6abbbe02b0d4147d1c4fbd0