Hi there,
On Tue, Jun 3, 2014 at 11:24 PM, Santiago Pericas-Geertsen <
Santiago.PericasGeertsen_at_oracle.com> wrote:
>
> On Jun 3, 2014, at 4:05 PM, arjan tijms <arjan.tijms_at_gmail.com> wrote:
>
> Pretty much everything in JSF applies to an MVC framework, since JSF
> already IS an MVC framework at its core and always has been.
>
> Maybe I wasn't clear in my e-mail, but I was referring to a _JAX-RS
> based_ MVC framework. Again, not every part of JSF applies here.
>
Right.
>
>
> Some, such as the Facelets templating language, could be plugged into a
>> JAX-RS based MVC framework
>>
>
> In the current way that things are implemented "just Facelets" (implying
> no JSF) would be questionable. Even if the view would use no explicit
> components, plain markup would still be compiled into UIInstructions, which
> has UIComponentBase as its super class. If anything, this particular class
> basically -is- JSF.
>
>
> No, form processing, for example, could potentially be very different to
> JSF in this framework.
>
I know, but what I meant is that Facelets as it is depends on core JSF
classes one way of the other.
Form processing, and then specifically the way in which the postback from
components could be handled in a controller that hasn't seen the view yet
(or will never see it) is a challenging task. I had some lengthy
discussions with Manfred from the Mojarra team about this very topic.
The thing is that all current components are written under the assumption
that their postback variables, both the names of the variables and its
content, are private to the component. For quite a lot of components,
especially the standard ones in JSF like h:inputText the name is very
predictable and the value is extremely simple (whatever the user gave as
input). This is thus not that difficult to process, but in general one can
not make that assumption as it are private variables one way or the other
and can theoretically change at any time between releases of a component.
That said, there is in JSF already a mechanism that controls the decoding,
namely the Renderer. See
http://docs.oracle.com/javaee/7/api/javax/faces/render/Renderer.html
(perhaps a better name for this class would have been EncoderDecoder or
something).
At any length, this particular class embeds all the knowledge that's needed
to decode parameters from the request. It may need some more brainstorming,
but with a small modification to this class and an addition to the ID
generation code for components, it might be quite doable to "manually"
extract the data posted by existing components without needing the original
view.
Alternatively JSF could introduce some new kind of contract where new
components can be more explicit about the data they post.
> IMO, whether JSF if second or third or whatever is beyond the point. We
> are not trying to compare Spring MVC vs. JSF; nor are we going to suggest
> that everyone should move away from JSF. However, the Java EE survey that
> was recently conducted indicated that 60% of the developers will like to
> see an MVC solution alongside JSF:
>
> https://java.net/downloads/javaee-spec/JavaEE8_Community_Survey_Results.pdf
>
> This is a very good indication that not everyone is satisfied with our EE
> offering, so this decision is about choice. Of all the frameworks (not
> named JSF) Spring MVC seems the most popular and the best fit for EE.
>
I interpreted the survey slightly differently, namely asking users if they
were interested in action oriented concepts, and if so which existing
framework should be looked at for inspiration. That could as well be
interpreted as whether users were interesting in extending the existing
action orientation in JSF (like view actions and such) with more elaborate
support. Part 3 of the survey even explicitly mentioned Manfred's JSF based
prototype.
And naturally people are not 100% satisfied, otherwise there would not be a
need for a JSF 2.3 and a Java EE 8 ;)
But the point is, the survey IMHO wasn't really clear about whether JSF
should be extended with more action oriented concepts or that a new action
based framework should be introduced. Without this being asked in a very
explicit way I think we can agree that users are interested in the
concepts, but cannot say in which exact form they would like to see that
realized.
It's perhaps a bit like Oracle asking if users were interested in
functional concepts for Java 8. The assumption was there that Java would be
extended with them (would get Lambdas), not that Oracle would just
introduce Haskell as its new or additional language ;)
> As far as the framework surveys, I agree with you there are some that
> contradicting results. The one I included above was just an example (and
> again I was not trying to compare Spring against JSF) there are many more
> that show Spring MVC being at or near the top, some of which you found as
> well.
>
I would be interested in seeing which other surveys or sources really show
Spring MVC leading by a large margin. Except for the rebellabs survey I
can't remember having seen anything else for the last few years.
Spring MVC is indeed often near the top, but so is JSF as you've seen.
So based on just that I don't think we can state that Spring MVC is the
most popular UI technology by a large margin. It's really not that clear.
There are contradicting results as you mention, with as the only constant
more or less that both Spring MVC and JSF are among the popular choices.
Kind regards,
Arjan Tijms