users@jax-rs-spec.java.net

[jax-rs-spec users] Re: [jsr339-experts] MVC

From: Joshua Wilson <javajoshw_at_gmail.com>
Date: Mon, 30 Jun 2014 21:32:44 -0400

Arjan,

I think I did not explain myself well, I'm sorry for that. First let me
say thank you for articulating that explanation. I believe it and agree
with. Second, I was only trying (in my limited and opinionated way) to
recount the opinions of others that I have encountered. They are not my
views but just a theory, flawed as it may be, as to the "driving force
behind the MVC spec". Also, I was making this hypothesis based on the
results of the Java EE 8 survey that lead to the discussion of having an
MVC spec and most people on the survey suggested something like Spring MVC.

I do think that Spring users will continue to use Spring MVC.

My opinion regarding changing JSF is only based on the idea that it is
component based and I do not think it should be changed to action based.
 If the JSF EG and community do want to change it, who am I to get in the
way. It is just my humble opinion. (that would make for some interesting
discussions though)

Thank you again for taking the time to reply in detail.

Joshua


On Mon, Jun 30, 2014 at 6:43 PM, arjan tijms <arjan.tijms_at_gmail.com> wrote:

> On Mon, Jun 30, 2014 at 9:11 PM, Joshua Wilson <javajoshw_at_gmail.com>
> wrote:
>
>> No, I think the driving factor is the existence of Spring MVC.
>>
>
> I appreciate the openness to clearly state that you think this is the
> driving factor. Right in the beginning I picked up various signals about
> this too, but nowhere was this really made explicit.
>
> If the goal is to have Spring MVC (Spring MVC like API) in Java EE and not
> a specific use case, then at least this is clear point to start discussing
> from. You may have guessed that I wouldn't agree with it ;), but it's a
> good point to start the discussion.
>
>
> I think that the community sees JSF as difficult due to it's early issues
>> and they do not equate it to Spring MVC.
>>
>
> Nobody will deny that JSF had severe early problems. The content
> interweaving issue, the one-URL behind problem, the many moving parts
> required to implement a custom component and the strong focus on POST-only,
> combined with a not yet mature offering of component sets did all not
> contribute to much love for JSF.
>
> However, as I've explained before and a couple of others have as well,
> this all changed rather radically with the release of JSF 2.0. Before that
> there was an "I hate JSF blog" pretty much every week. After JSF 2.0 became
> known this stream pretty much dried up, I guess for lack of ammunition.
>
> For instance, the argument: "but JSF components are so difficult to
> create!" basically evaporated with the introduction of composite components
> and the simplification of creating Java based custom components. See for
> example the following blog post I wrote about this:
> http://jdevelopment.nl/simple-java-based-jsf-22-custom-component It's a
> far cry from the work that needed to be done in JSF 1.x. And still, as
> simple as it currently is, there's still some room left to make it even
> simpler.
>
> Currently what I see as a recurring pattern is that someone on a forum or
> site like Reddit who has obviously not touched JSF since 1.x will complain
> about e.g. JSF being POST only, not having something like The Flash, etc
> and then a few other users immediately pointing out that all of this has
> been addressed years ago and that JSF 2.x works like a charm.
>
> You basically have two groups of users thus; those who know about JSF 2.x,
> and those that only knew 1.x. The former group is getting bigger every day,
> while the latter is continuously shrinking.
>
> With a continuous effort on making the JSF core even simpler and at the
> same time more powerful, combined with efforts from the JSF ecosystem (like
> PrimeFaces, RichFaces, and hopefully my own and Bauke's contribution of
> OmniFaces among others), I think we can only increase the speed with which
> that former group is growing and that latter one is shrinking.
>
>
> Therefor they desire a "Spring MVC" like API/SPI in Java.
>>
>
> I personally don't see that the larger community desires this. As I
> pointed out earlier in this discussion (see
> https://java.net/projects/jax-rs-spec/lists/users/archive/2014-06/message/35)
> the evidence does not really support the thesis that a majority of users
> use Spring MVC.
>
> If we can conclude anything from the sources I looked at, it's perhaps
> that:
>
> 1. The web framework market remains highly fragmented
> 2. Both Spring MVC and JSF are among the top ranked and most frequently
> used frameworks
>
> If Java EE would have shipped with a framework that's often at the very
> bottom of those polls and surveys (as EJB 2 once was), while Spring MVC
> would consistently be at number 1 with a large margin, then it would be
> rather clear cut. But as the evidence shows, this is far from the case.
>
> Maybe Spring MVC has a user base that has a vocal minority that's very
> actively advocating the technology, but so do many of the other web
> frameworks.
>
> And there's people who say they don't like Spring MVC as well, e.g.
>
> "[Spring MVC] is more difficult to work with and less productive than JSF
> and CDI now" (
> http://www.reddit.com/r/java/comments/26vrze/id_like_to_build_a_modern_web_app_using_java
> )
>
> "I had to work with [Spring MVC] in 2008 and it wasn't much more than
> standard JSP. I thought it was an abomination to work with"
>
> "Just looking at a Spring MVC tutorial to see what it's about again. First
> though; oh yeah, this nonsense. Every controller is almost a Servlet, also
> with low-level Servlet things exposed in a kind of backing bean"
>
> And when looking at some code that was given at the above link as an
> example of why Spring MVC would be simpler, we see the following:
>
> SPRING MVC:
>
> @Named
> @RequestMapping("/appointments")
> public class AppointmentsController {
>
> private final AppointmentBook appointmentBook;
>
> @Inject
> public AppointmentsController(AppointmentBook appointmentBook) {
> this.appointmentBook = appointmentBook;
> }
>
> @RequestMapping(value="/new", method = RequestMethod.GET)
> public String getNewForm(Model model) {
> model.addAttribute("appointment", new Appointment();
> return "appointment-edit";
> }
>
> @RequestMapping(value="/new", method = RequestMethod.POST)
> public String add(@Valid Appointment appointment, BindingResult
> result, RedirectAttributes redirectAttributes) {
> if (result.hasErrors()) {
> return "appointments/new";
> }
> appointmentBook.addAppointment(appointment);
> redirectAttributes.addFlashAttribute("message", "Successfully
> added "+appointment.getTitle();
> return "redirect:/appointments";
> }
>
> }
>
> JSF
>
> @Named
> @ViewScoped
> public class NewAppointmentsBacking {
>
> @Inject
> private AppointmentBook appointmentBook;
>
> private Appointment appointment = new Appointment();
>
> public String saveUser() {
> appointmentBook.addAppointment(appointment);
> addFlashMessage("Successfully added " + appointment.getTitle());
>
> return "/appointments?faces-redirect=true";
> }
>
> public Appointment getAppointment() {
> return appointment;
> }
> }
>
> Just some example that people actually used. I'm not sure whether the
> Spring MVC controller is really simpler, and this is for a rather common
> use case. The link above also gives a somewhat more uncommon example of
> rendering an image from memory, but there too the Spring MVC code as
> demonstrated is not clearly simpler than the JSF code. In fact, I'd argue
> that the JSF code is simpler (of course I'm biased knowing JSF better than
> Spring MVC, but still).
>
> At any length the difference in code complexity and amount of lines of
> code as demonstrated by these examples is a FAR cry from the difference we
> once saw between EJB 2 session beans and Spring Beans, and between EJB 2
> entity beans and Hibernate. That was a huge day and night difference. In
> this case, I don't know. As someone else on this list said, there are
> probably more similarities than differences, and a lot of the differences
> shown here for typical use cases are more stylistic in nature than anything
> else.
>
>
> 1) Do we create a new action based MVC spec?
>> 2) Do we change JSF?
>> 3) Do we let Spring MVC continue as the dominate player in the action
>> based MVC arena?
>>
>> My preference is for number 1. Though I think Bill Burke has an
>> interesting idea that might be worth considering about just creating an SPI
>> for all other MVC frameworks to adhere to. (I need to think more on that
>> one.)
>>
>> Personally I do not think 2 is an option. And it appears the community
>> does not want 3.
>>
>
> I think number 2 is always an option. There are plenty of things on the
> JSF issue tracker (not necessarily all related to the action-oriented
> effort) that in general aim to make JSF even simpler.
>
> I wonder about 3. Why would the community not want this? Why don't they
> just use Spring MVC if they want Spring MVC? What if people just want to
> use Spring because it's Spring, and if Java EE (Oracle in their eyes)
> includes a Spring MVC clone, wouldn't they be wary of using that because of
> some possible bias against Java EE (maybe because of a bad experience with
> J2EE 1.4) that made them choose Spring in the first place?
>
> Regards,
> Arjan
>