users@jax-rs-spec.java.net

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

From: Leonardo Uribe <lu4242_at_gmail.com>
Date: Mon, 30 Jun 2014 13:47:35 -0500

2014-06-30 12:05 GMT-05:00 Joshua Wilson <javajoshw_at_gmail.com>:
> Arjan,
>
JW> To answer you question about why use action based MVC please consider this
JW> quote from a post on stackoverflow.
JW>
JW> --Start--
JW> Some may opt that the major disadvantage of JSF is that it allows very
JW> little fine-grained control over the generated HTML/CSS/JS. That's not JSF's
JW> own, that's just because it's a component based MVC framework, not a request
JW> (action) based MVC framework. If a high degree of controlling the
JW> HTML/CSS/JS is your major requirement when considering a MVC framework, then
JW> you should already not be looking at a component based MVC framework, but at
JW> a request based MVC framework like Spring MVC. You only need to take into
JW> account that you've to write all that HTML/CSS/JS boilerplate yourself.
JW> --End--
JW>
JW> http://stackoverflow.com/questions/3623911/what-are-the-main-disadvantages-of-java-server-faces-2-0/
JW>

Well, that is something questionable. With JSF you can have full
controll of the generated HTML/CSS/JS if you want. But the integration
between the javascript and the server side is not straightforward,
because this is usually hidden by the component implementations.
That's the point, how to make that part more simple, like in an action
oriented framework.

I would like to hear the reasons to support the "action based MVC"
approach. This is my list of key points:

* For some developers it can be simpler to understand.
* Some javascript libraries are built to use this approach
(questionable, but the truth is JSF can do it better).
* Many frameworks out there relies on this approach, but with different syntax.

* Template engines does not deal with resource handling (add css/js
inside <head> ...). JSF solves it (since 2.0).
* Not a good way to create reusable code, because it doesn't solve the
id problem. JSF solves it (since 1.0).

Is there any incentive to move from JSF to an "action based MVC"
approach if is out there in Java EE? in my personal opinion no,
because there is not a real advantage of doing so. But if you are an
user of Spring MVC, Grails, Play or whatever other similar framework
out there, and you have a standard option inside Java EE to do it,
there is a good incentive to get in.

Leonardo

> Joshua Wilson
>
>
> On Mon, Jun 30, 2014 at 12:41 PM, arjan tijms <arjan.tijms_at_gmail.com> wrote:
>>
>> On Mon, Jun 30, 2014 at 5:26 PM, Reza Rahman <Reza.Rahman_at_oracle.com>
>> wrote:
>>>
>>> I have to admit I personally think we could have worded the survey a bit
>>> better. MVC was in fact the wrong term to use in hindsight. An action
>>> oriented framework would have been more accurate.
>>
>>
>> As a matter of fact, one of the very earliest wording from the EE EG did
>> use the term "action-oriented web framework", see
>> https://java.net/downloads/javaee-spec/JavaEE-EG-meeting-results.pdf :
>>
>> Java EE 8 Idea
>> JAX-RS MVC
>>
>> * Action-oriented web framework.
>> * Do we really need another standard web framework?
>> * Would this be The One?
>>
>> Such a small amount of text, but it does say so much already. It clearly
>> mentions that it's about action-oriented, and it poses the questions about
>> whether a fullstack framework like Java EE really needs two standard web
>> frameworks and whether this new one should be The One. I interpreted this
>> last question as wondering whether it would ultimately replace JSF (maybe
>> that interpretation is not correct, it's just an interpretation).
>>
>>
>>>
>>> That being said, I do think from the comments to the survey that the
>>> respondents actually understood exactly what we meant.
>>
>>
>> That may be true indeed. In a way I think this is unfortunate though, as
>> now Java EE too is more or less "helping" the increasingly common perception
>> that MVC is strictly (or mostly) about the way Spring MVC has been doing
>> MVC.
>>
>>>
>>> In fact, there may be sound reasons to still carry forward the MVC term
>>> with this effort if we decide to go forward with it.
>>
>>
>> From a marketing / PR point of view I can surely understand the reasoning.
>> Both Spring MVC and ASP.NET MVC that use this specific model are well known
>> names. Spring MVC, ASP.NET MVC, Java EE MVC... I agree it does have a
>> certain ring to it ;)
>>
>> But from a technical point of view, especially for someone who has done
>> the more classic MVC (as introduced by smalltalk and as used in various
>> desktop toolkits) I'm not the biggest fan of this.
>>
>>>
>>> An additional value to keeping JSF at arms length in this particular case
>>> is that the users of this new solution are likely to be averse to JSF in the
>>> first place, potentially needlessly limiting the success of the effort.
>>
>>
>> I certainly recognize this sentiment and there absolutely is an element of
>> truth to it. On the other hand there seems to be a similar kind of aversion
>> among certain groups of people to the names "Java EE", "Oracle" and in fact
>> "Java" in general. Case in point; read the comments posted for many
>> Java/Java EE/Oracle related articles posted at say /r/programming at Reddit
>> or hackers news. Naturally we would not want to keep any of those names at
>> arms length. Instead, I think our common goal is to improve Java and Java EE
>> in any way we can, and stress the point over and over again how much those
>> technologies improved and how little of the old criticises still hold.
>>
>> For Java, Java EE and JSF I see the fruits of this everywhere. Half a
>> decade ago they were all pretty much dirty words in the blogosphere. These
>> days there are as mentioned above people averse to these technologies, but
>> also an increasing amount of people defending it. A few years ago there
>> would be a crowd of say 15 people attacking Java EE on one of the many
>> Spring vs Java EE wars at TheServerSide and maybe one lone person sticking
>> up for Java EE, while now on similar discussions at e.g. Reddit it's more
>> like halve of the community sticking up for Java EE. A similar thing holds
>> for JSF. Some 5 years ago many people were attacking JSF in discussions,
>> these days at least half of the community or more is backing JSF. In recent
>> discussions at places like Reddit again I'd say it's more like 1 or 2 people
>> attacking JSF, with 4 or 5 defending it. It's quite a remarkable difference.
>>
>>
>>>
>>> I say this honestly from the perspective of a long time supporter of the
>>> JSF ecosystem that would still likely never choose to use an action oriented
>>> framework myself. The practical reality in this case is that the voice of
>>> the community may be unwise to not take very seriously.
>>
>>
>> Absolutely!
>>
>> When the community said that EJB was too complicated with its myriad of
>> required interfaces to implement, it was a good thing that the EG listened
>> and removed that requirement. When the community said that it's unacceptable
>> that JSF was so totally focussed on POST, it was a good that that the EG
>> made GET first class as well in JSF.
>>
>> With the action-oriented effort it's a bit less clear IMHO. If you look at
>> the amount of posts spend on this topic already, then I think it's maybe one
>> of the most discussed topics ever since these kinds of discussions were held
>> publicly. Yet, I still haven't seen a really clear example of why the
>> action-oriented model is needed.
>>
>> I'm absolutely not saying that the model is not needed, just that there
>> haven't been any examples posted about use cases that work well for
>> action-oriented and don't work well for MVC pull. Up until now it mostly has
>> been the case of a "we need action-oriented" and less about "with
>> action-oriented you can do [this and that] without needing to do [such and
>> so]", or "for this use case you need 100 lines of code with MVC pull and
>> only 20 lines of code with action-oriented", etc.
>>
>> With EJB Entity Beans vs JPA for instance these examples were very clear.
>> I still hope to see some clear example for action-oriented.
>>
>> Regards,
>> Arjan
>>
>>
>>>
>>>
>>> Please note that any views expressed here are my own and may not
>>> necessarily reflect the position of Oracle as a company.
>>>
>>>
>>> On 6/30/2014 10:55 AM, arjan tijms wrote:
>>>
>>> On Mon, Jun 30, 2014 at 4:25 PM, Sergey Beryozkin <sberyozkin_at_talend.com>
>>> wrote:
>>>>
>>>> Hold on. I don't like you making the assumptions about me kind of
>>>> dismissing that the conversation about the intersection between JAX-RS and
>>>> JSF should take place. Neither I like you quoting single lines from my
>>>> earlier comments which loses the context.
>>>
>>>
>>> I'm sorry if I misquoted you. I just tried to keep the amounts of quoted
>>> text to a minimal.
>>>
>>>
>>>>>
>>>>> Correct me if I'm wrong, but what I think you're saying here is that
>>>>> you
>>>>> don't care whether JSF will use JAX-RS as a foundation or not?
>>>>
>>>>
>>>> You got it wrong. Let me clarify: I do not mind if Java EE developers
>>>> working with JAX-RS will start using JSF for the MVC work or not once the
>>>> JAX-RS MVC work is done, and presumably JSF becoming a de-facto 'consumer'
>>>> of JAX-RS MVC.
>>>
>>>
>>> Okay, that's indeed what I thought you were saying. Thanks for the
>>> clarification though ;)
>>>
>>>
>>>>
>>>> That is not important for me. What is important for me is that I or
>>>> other users can work with JAX-RS MVC without having to depend on JSF
>>>
>>>
>>> So this is the part I guess we just have different opinions about. That
>>> doesn't matter of course, since if we all agreed with each other from the
>>> get-go there wouldn't be much discussion needed, would there? Let's agree
>>> that we disagree on this specific part.
>>>
>>>
>>>
>>>
>>>>> To sum up I propose to take the following into account:
>>>>>
>>>>> 1. Just "MVC" is too broad
>>>>> 2. Use "MVC push"/"action oriented" for what Spring MVC does
>>>>> 3. Use "MVC pull" for what JSF does
>>>>>
>>>>> Would that make things more clear?
>>>>
>>>>
>>>> AFAIK we have not started a technical discussion yet and as such I'm not
>>>> sure why are we talking about these technical distinctions here
>>>
>>>
>>> Well, the general discussion about this has started (as we're having this
>>> discussion now). I don't think it's necessary for the discussion to become
>>> deeply technical in order to make this subtle but important distinction.
>>>
>>> In much of the communication towards the user, e.g. via the Java EE 8
>>> survey, it's now communicated that Java EE 8 will either get "an MVC
>>> framework" or will get "an additional MVC framework". For existing Java EE
>>> users this may sound confusing. You can either interpret it as saying that
>>> JSF is thus not an MVC framework,or wonder why two of the same things are
>>> needed.
>>>
>>> The simple answer is that JSF IS an MVC framework too, but of a different
>>> kind, and that the new work is not about an identical thing to JSF but a
>>> different kind of MVC. Claiming MVC to be solely about the kind of MVC that
>>> Spring MVC does is IMHO not correct.
>>>
>>> Much of this confusion can be avoided by consistently talking about MVC
>>> push or action oriented. Even without going into the technical details I
>>> think we can agree that everything that's planned for JAX-RS MVC is about
>>> the push / action oriented variety.
>>>
>>> Regards,
>>> Arjan
>>>
>>>
>>
>