Why?
Why not JSF? Why another MVC framework?
The Java community was polled about what new features they wanted to see in Java EE
8. While 61% of respondents answered "Yes"
to the question as to whether we should provide MVC support alongside JSF, only
26% felt that they could identify an existing technology here. Most requesters want a formal Java MVC API
that can compare to Spring MVC. The third phase of the poll looked at all the technologies that received 60% or more votes. In that poll there were 13 areas and the MVC JSR ranked 5th.
This JSR is in no way
meant to take anything away from JSF. (In fact in the new JSF proposal
they are planning on supporting the MVC JSR.) It is instead intended to provide
an alternative implementation to the MVC pattern. JSF is a component
based MVC framework, while this JSR is a request (action) based MVC framework. The main difference is that JSF allows very little fine-grained control
over the generated HTML/CSS/JS, whereas this JSR will provide that detailed
control. Both framework styles have their place and value but one is not the
other.
The MVC JSR proposal was just announced on the JAX-RS mailing list and will be led by Santiago Pericas-Geertsen and Manfred Riem from Oracle.
I
have been thinking about MVC for a while now. I had actually considered submitting my own proposal until I found out
that Oracle already had one in the works. After comparing notes with Santiago and Manfred, we realized we could
work together on it. One of the biggest reasons that I wanted to work on the MVC spec is that I have spent years working with Spring and Spring MVC. In fact, my current role at Red Hat is the Spring lead for JBoss. I make sure that Spring works on JBoss/WildFly. Additionally I have worked with server-side frameworks like Struts and VRaptor and client-side frameworks like Backbone.js and Angular.js. That is why it felt like a perfect fit for me.
What is MVC, if you are still wondering? For those of you that are unfamiliar with this design pattern, here is a bit of an overview and some insight into what I hope we build.
The Model View
Controller (MVC) design consists of three kinds of objects. The Model is the
application or data object, the View is its screen presentation, and the
Controller defines the way the user interface reacts to user input. Before
the use of the MVC pattern, user interface designs tended to lump these objects
together. For example, JSPs sometimes merge database code, page design code,
and control flow code. In practice, we find that unless these concerns are
separated, larger applications become difficult to maintain. MVC decouples
these concerns to increase flexibility and reuse.
Frequently application
developers implement the MVC pattern in applications themselves which is
expensive and error prone. This specification aims to help developers create
web applications that utilize the MVC architecture without reinventing the
wheel. This shortens the development time of applications using the MVC
pattern.
The decoupling of the
View and the Model is done by establishing a notify protocol. A View must
ensure that its appearance reflects the state of the Model. Whenever the
Model’s data changes, the Model notifies Views that depend on it. In response,
each View gets an opportunity to update itself. This approach lets multiple
Views be attached to a Model to provide different presentations. New Views for
a Model can be created without rewriting it.
Depending on context,
users want to see the same basic Model information in different ways.
Separating out the View from the Model and the Controller allows the
development of multiple Views from the same Model. Most noticeably this
could be providing the same Model to a rich client, a Web browser, a remote
API, and a command-line interface. Even within a single Web interface you might
have different customer pages at different points in an application.
After working with both
server-side and client-side MVC frameworks; I have a simple goal. Make MVC easy to adopt and powerful enough to
use. Many frameworks are cumbersome to
learn, while others are too light weight to be of any real value. I am aiming at striking a balance between those two.
Additionally, I will be
able to make sure the MVC API is implemented on Red Hat JBoss (WildFly) in a timely fashion.
