Hi
KM> I've heard that Spring MVC developers are using Thymeleaf, but I don't
KM> know prevalent that is, and I don't know how it compares to Facelets.
Thymeleaf does something very similar to what Facelets does. It parses XML
files to build a view and then render it. It is supposed to be the
replacement for JSP for Spring MVC users, because it has improved
templating support. This is how a file with Thymeleaf looks like:
<html xmlns="
http://www.w3.org/1999/xhtml"
xmlns:th="
http://www.thymeleaf.org">
<head th:include="layout/header :: header">
</head>
...
<form method="post" th:action="${'home.do'}" th:object="${loginForm}">
...
<input th:field="*{username}" style="width: 175px;"/>
<div class="errors" th:if="${#fields.hasErrors('username')}"
th:text="${#fields.errors('username')}"></div>
It looks similar to facelets. There is a namespace, and the attributes marked
with this namespace has some special behavior over the final markup. The
thing is everything that you can see here can be done just doing some small
changes over Facelets. Keep in mind that JSF/Facelets is a lot faster than
Thymeleaf, so a solution using pure JSF/MyFaces could perform faster than
the combination Spring MVC/Thymeleaf.
Looking this syntax you have the impression that what we really need is make
Facelets more extensible, so we can plug custom namespaces with custom special
attributes, but please note there is some integration between the template
engine and the front controller (to get the loginForm object, the fields ...)
that needs to be done. Take Facelets out of JSF is nonsense, instead make
Facelets more pluggable makes a lot of sense.
AT> One aspect of the discussion is that when using Facelets supposedly
AT> separately, you'll still be using components and JSF. Facelets uses
AT> UIComponentBase which uses things like the FacesContext and other
AT> infrastructure that has been set up by the FacesServlet.
Yes, Facelets and any template engine you can imagine requires the same
plumbing, no matter how you name it.
AT> An other aspect is that components actually DO work when using Spring MVC
AT> with Facelets, but only the ones that render something and don't depend
AT> on a postback. So practically Bauke is correct and giving any other answer
AT> would only confuse people on SO, but technically it's more subtle than
AT> that. There are indeed components that don't post anything back, like
AT> e.g. h:panelGroup or p:graphicImage. We (Bauke and I among others) build
AT> the public part of
http://m4n.nl in that way; it uses Facelets for view
AT> compositing and components, but no components that postback anything.
Any html markup in facelets is backed by a UILeaf component that at the end
extends from UIComponent, and UILeaf is a component that just renders markup,
but doesn't have any behavior in a postback.
AT> The downside is that the view thus needs to be available for processing
AT> the submitted data, and that there are concerns about the memory and cpu
AT> resource drain involved with that. While this may be an issue to some
AT> degree, I saw some interesting research from Leonardo where despite not
AT> needing the original view to process postbacks, Spring MVC still put more
AT> pressure on the garbage collector.
The evidence suggest that you cannot really save a lot of memory/cpu using
an action source framework, because JSF can execute the tree traversal very
quickly, and there are other things that has more weight over the request
like render the page and so on. An action source framework needs to do some
processing that is comparable at every request, and that puts more pressure
over memory, because JSF algorithm can use memory more efficiently. So, a
solution using Spring MVC/JSP uses 40% more memory than a solution using
JSF/MyFaces.
AT> But the fact that the view needs to be available is the biggest challenge
AT> of making JSF compatible with action oriented concepts for the postback.
AT> The initial GET is no problem at all, and is already done in a kind of
AT> hybrid way by today's view action and in a more pure action oriented way
AT> by both Manfred's and Leonardo's prototypes (and in fact by a prototype
AT> I experimented with myself some time ago but never published)
Yes, in some situations, you don't need to build the view, but you need the
context to grab some data directly from the beans. In this scenario,
use an action oriented approach make sense.
Leonardo Uribe
2014-06-04 8:01 GMT-05:00 Kito Mann <kito.mann_at_virtua.com>:
>
>
> On Wed, Jun 4, 2014 at 6:22 AM, Werner Keil <werner.keil_at_gmail.com> wrote:
>>
>> Hi,
>>
>> Comparing StackOverflow and JAXEnter (where the Vaadin numbers seem overly
>> high, most others look representative) StackOverflow analysis tells a
>> slightly different story.
>>
>> Even more enlightning is another StackOverflow answer to
>> http://stackoverflow.com/questions/18744910/using-jsf-as-view-technology-of-spring-mvc
>>
>> >You can use Spring MVC with JSP view technology. You can also use Spring
>> > MVC with Facelets view technology. But you can not use Spring MVC with JSF
>> > components let alone >with JSF component libraries like PrimeFaces. This is
>> > not making any sense. If you want to use the same UI as PrimeFaces, just
>> > grab jQuery UI. It's also exactly what PrimeFaces >is using under the
>> > covers. PrimeFaces is a jQuery-based JSF component library.
>
>
> Just to clarify, PrimeFaces is not related to jQuery UI except for the CSS
> selectors used by ThemeRoller. Almost all of the components use custom JS
> that use jQuery underneath (not jQuery UI) with, of course, the JSF
> integration layer (there may be a couple that wrap jQuery UI plugins, but
> that's out of like 100 components).
>
> I've heard that Spring MVC developers are using Thymeleaf, but I don't know
> prevalent that is, and I don't know how it compares to Facelets.
>>
>>
>>
>> So essentially Spring MVC can at least use Facelets, the same underlying
>> (preferred and after EE 7 sole) document format JSF, does, too, and it would
>> be interesting to see stats on that, needless to say, JSP was also a Java EE
>> standard, Spring picked up and mixed into its basket of Java standards and
>> proprietary or home-grown technologies.
>>
>> Another part of that answer "PrimeFaces is a jQuery-based JSF component
>> library." makes clear, that http://devrates.com figures are misleading, not
>> to say "bullshit". They measure individual projects, in most cases simply on
>> a "repository" level, so it's up to project owners and funders, how modular
>> they define these. PrimeFaces, RichFaces (or OpenFaces) may be separate
>> projects, but they are both component libraries for JSF, hence a figure for
>> JSF should combine the two (and maybe more) resulting in a clear lead for
>> JSF there, too;-)
>>
>> Werner
>>
>> On Wed, Jun 4, 2014 at 11:15 AM, <users-request_at_jax-rs-spec.java.net>
>> wrote:
>>>
>>> Table of contents:
>>>
>>> 26. [jax-rs-spec users] Re: [jsr339-experts] MVC - arjan tijms
>>> <arjan.tijms_at_gmail.com>
>>> 27. [jax-rs-spec users] Re: [jsr339-experts] MVC - Santiago
>>> Pericas-Geertsen <Santiago.PericasGeertsen_at_oracle.com>
>>> 28. [jax-rs-spec users] Re: [jsr339-experts] MVC - arjan tijms
>>> <arjan.tijms_at_gmail.com>
>>> 29. [jax-rs-spec users] Re: Hypermedia for structural links - Ivan
>>> Junckes Filho <ivanjunckes_at_gmail.com>
>>>
>>>
>>>
>>> ---------- Forwarded message ----------
>>> From: arjan tijms <arjan.tijms_at_gmail.com>
>>> To: users_at_jax-rs-spec.java.net
>>> Cc:
>>> Date: Tue, 3 Jun 2014 22:05:53 +0200
>>> Subject: [jax-rs-spec users] Re: [jsr339-experts] MVC
>>> Hi,
>>>
>>> On Tuesday, June 3, 2014, Santiago Pericas-Geertsen wrote:
>>>>
>>>> JSF has a number of different parts, not all of which are applicable to
>>>> an MVC framework.
>>>
>>>
>>> Maybe it's important to be aware of some of the terminology to make it
>>> clear what we're really talking about.
>>>
>>> Pretty much everything in JSF applies to an MVC framework, since JSF
>>> already IS an MVC framework at its core and always has been. In fact it
>>> might even be the case that JSF is closer to the original MVC model as
>>> introduced by smalltalk than Spring MVC is.
>>>
>>> What we're talking about here is action oriented vs component based, or
>>> alternatively MVC push vs MVC pull.
>>>
>>> Although I understand the usage of the term from a marketing perspective,
>>> we really should realize that Spring MVC did not invent the MVC model and
>>> that the particular way in which Spring MVC does things is not the
>>> stereotypical way to do MVC. It's -a- way, but not -the- way for sure.
>>>
>>>
>>>>
>>>> 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.
>>>
>>>
>>>>
>>>> As far as to why MVC? The world domination of "thick clients" (Angular,
>>>> etc.) is a bit overblown. Yes, these technologies are great and will
>>>> continue to evolve in the next few years. However, (i) historically, there
>>>> has not been a single technology dominating the UI space and (ii) these
>>>> paradigm shifts do not happen overnight.
>>>>
>>>> We have not arrived to the decision of supporting MVC without a careful
>>>> consideration of (i) community feedback and (ii) research data. MVC (and
>>>> Spring MVC in particular) is the most popular Java UI technology by a good
>>>> margin:
>>>>
>>>> https://twitter.com/RebelLabs/status/471680296119971841/photo/1
>>>>
>>>> And this is just an example, there are many other reports like that.
>>>
>>>
>>> I don't entirely agree with the above conclusion. While I don't contest
>>> that Spring MVC is indeed popular, I find the 40% somewhat remarkable. Other
>>> sources that I've seen don't really support this.
>>>
>>> In fact, many surveys seem to put JSF at number 1 or 2 and put Spring MVC
>>> at a lower place. You just happened to pick the one where Spring MVC wins by
>>> a large margin.
>>>
>>> A number of surveys have been collected here:
>>> https://henk53.wordpress.com/2011/10/12/reply-to-comparing-java-web-frameworks
>>>
>>> In the rebellabs surveys Spring MVC indeed wins, but JSF is at number 2.
>>> Is this 1 position difference really worth the potential confusion?
>>>
>>> If we take a look at the poll that JAXenter did some time back,
>>> specifically asking for the *preferred* framework, the list was as follows:
>>>
>>> Vaadin (18%)
>>> JSF (16%)
>>> Grails (15%)
>>> Play! (10%)
>>> Wicket (8%)
>>> ZK (7%)
>>> Spring MVC (6%)
>>> GWT (5%)
>>> Ruby on Rails (3%)
>>> Lift (2%)
>>> JAX-RS (Jersey) (2%)
>>> Struts (1%)
>>> Tapestry (1%)
>>> Flex (1%)
>>> Stripes (1%)
>>> Spring Roo (0%)
>>> Roma (0%)
>>> JavaFX (0%)
>>> Click (0%)
>>> Anderes (4%)
>>>
>>> (see
>>> http://it-republik.de/jaxenter/news/Und-das-populaerste-Webframework-ist...-060497.html)
>>>
>>> Based on the outcome of this survey, it should thus be Vaadin that is
>>> considered the most popular UI technology, although not by a great margin.
>>> As you can see, JSF is right behind it at number 2. Spring MVC suddenly
>>> doesn't seem to be the most popular one at all with only 6% of the votes.
>>>
>>> In the OIO compass, the result was as follows:
>>>
>>> JSF (32%)
>>> Spring MVC (16%)
>>> GWT (16%)
>>> Grails (8%)
>>> Struts 2 (8%)
>>> Other (21%)
>>>
>>> (see
>>> http://www.oio.de/public/java/java-web-frameworks-vergleich/jsf-vs-gwt-studie.htm#a13)
>>>
>>> This time it's thus JSF that wins by a large margin.
>>>
>>> If we take a look at the results of http://devrates.com (a website
>>> dedicated to measuring technology popularity), we currently see the
>>> following results for Java frameworks:
>>>
>>> Grails (9.3)
>>> PrimeFaces (8.8)
>>> Vaadin (8.5)
>>> Play (8.2)
>>> Tapestry (8.2)
>>> Struts (7.5)
>>> RichFaces (7.6)
>>> Wicket (7.6)
>>> GWT (7.2)
>>>
>>> According to this list it's thus Grails that's the most popular. For some
>>> reason Spring MVC isn't even there. PrimeFaces (which thus implies JSF) is
>>> at number 2.
>>>
>>> Over to stackoverflow.com, where we currently see the following activity
>>> measured in total number of questions:
>>>
>>> JSF (31503)
>>> http://stackoverflow.com/questions/tagged/jsf+or+jsf-2+or+primefaces
>>> Spring MVC (17956) http://stackoverflow.com/questions/tagged/spring-mvc
>>> Grails (16600) http://stackoverflow.com/questions/tagged/grails
>>> GWT (16399) http://stackoverflow.com/questions/tagged/gwt
>>> Struts (10649)
>>> http://stackoverflow.com/questions/tagged/struts+or+struts2
>>> Play (9998)
>>> http://stackoverflow.com/questions/tagged/playframework-2.0+or+playframework
>>> Wicket (2294) http://stackoverflow.com/questions/tagged/wicket
>>> Vaadin (1547) http://stackoverflow.com/questions/tagged/vaadin
>>> Tapestry (662) http://stackoverflow.com/questions/tagged/tapestry
>>>
>>> According to this list JSF is again the most popular by a large margin.
>>>
>>> Looking at Google trends, comparing PrimeFaces vs Spring MVC, it can be
>>> see that at this moment both have the exact same growth curve:
>>> http://www.google.com/trends/explore#q=PrimeFaces%2C%20Spring%20MVC
>>>
>>> Looking at job trends, there's an another remarkable similarity. This
>>> time JSF and Spring MVC have nearly the exact same *decline* curve:
>>> http://www.indeed.com/jobtrends?q=jsf%2C+%22spring+mvc%22 Adding some more
>>> frameworks shows the others are declining too, but at the moment the order
>>> is:
>>>
>>> JSF
>>> Spring MVC
>>> GWT
>>> Grails
>>> Wicket
>>> Vaadin
>>> Tapestry
>>>
>>> (see
>>> http://www.indeed.com/jobtrends?q=jsf+java%2C+%22spring+mvc%22+java%2C+grails+java%2C+vaadin+java%2C+gwt+java%2C+wicket+java%2C)
>>>
>>> Here too JSF is the number one of the ones included in the query.
>>>
>>> All in all I think these are a fair amount of sources to look at, and as
>>> seen in at least these ones JSF is basically everywhere at position 1 or 2,
>>> and except for the rebellabs survey Spring MVC doesn't really seem to be the
>>> most popular UI technology by a large margin.
>>>
>>> And to give a few other data points for the general question of whether
>>> JSF is or is not popular; articles about our library OmniFaces generally get
>>> favorable upvotes at places like reddit, see e.g. the posts about our latest
>>> release http://reddit.com/r/java/comments/2743ne/omnifaces_18_released and
>>> http://reddit.com/r/java/comments/27502d/new_release_of_omnifaces_sees_light_of_day
>>>
>>> Furthermore our JSF page at zeef.com does quite well (see
>>> https://jsf.zeef.com) and on my Java EE 7 page, the JSF links together have
>>> over 5 times more clicks than links in any other block except for the
>>> general Java EE 7 block (see https://javaee7.zeef.com).
>>>
>>> Kind regards,
>>> Arjan
>>>
>>>
>>>
>>> ---------- Forwarded message ----------
>>> From: Santiago Pericas-Geertsen <Santiago.PericasGeertsen_at_oracle.com>
>>> To: arjan tijms <arjan.tijms_at_gmail.com>
>>> Cc: users_at_jax-rs-spec.java.net
>>> Date: Tue, 3 Jun 2014 17:24:18 -0400
>>> Subject: [jax-rs-spec users] Re: [jsr339-experts] MVC
>>>
>>> On Jun 3, 2014, at 4:05 PM, arjan tijms <arjan.tijms_at_gmail.com> wrote:
>>>
>>> Hi,
>>>
>>> On Tuesday, June 3, 2014, Santiago Pericas-Geertsen wrote:
>>>>
>>>> JSF has a number of different parts, not all of which are applicable to
>>>> an MVC framework.
>>>
>>>
>>> Maybe it's important to be aware of some of the terminology to make it
>>> clear what we're really talking about.
>>>
>>> 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.
>>>
>>>>
>>>> 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.
>>>
>>>
>>>
>>> As far as to why MVC? The world domination of "thick clients" (Angular,
>>> etc.) is a bit overblown. Yes, these technologies are great and will
>>> continue to evolve in the next few years. However, (i) historically, there
>>> has not been a single technology dominating the UI space and (ii) these
>>> paradigm shifts do not happen overnight.
>>>>
>>>>
>>>> We have not arrived to the decision of supporting MVC without a careful
>>>> consideration of (i) community feedback and (ii) research data. MVC (and
>>>> Spring MVC in particular) is the most popular Java UI technology by a good
>>>> margin:
>>>>
>>>> https://twitter.com/RebelLabs/status/471680296119971841/photo/1
>>>>
>>>> And this is just an example, there are many other reports like that.
>>>
>>>
>>> I don't entirely agree with the above conclusion. While I don't contest
>>> that Spring MVC is indeed popular, I find the 40% somewhat remarkable. Other
>>> sources that I've seen don't really support this.
>>>
>>> In fact, many surveys seem to put JSF at number 1 or 2 and put Spring MVC
>>> at a lower place. You just happened to pick the one where Spring MVC wins by
>>> a large margin.
>>>
>>> A number of surveys have been collected here:
>>> https://henk53.wordpress.com/2011/10/12/reply-to-comparing-java-web-frameworks
>>>
>>> In the rebellabs surveys Spring MVC indeed wins, but JSF is at number 2.
>>> Is this 1 position difference really worth the potential confusion?
>>>
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> -- Santiago
>>>
>>>
>>>
>>>
>>> ---------- Forwarded message ----------
>>> From: arjan tijms <arjan.tijms_at_gmail.com>
>>> To: Santiago Pericas-Geertsen <Santiago.PericasGeertsen_at_oracle.com>
>>> Cc: users_at_jax-rs-spec.java.net
>>> Date: Wed, 4 Jun 2014 01:15:01 +0200
>>> Subject: [jax-rs-spec users] Re: [jsr339-experts] MVC
>>> 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
>>>
>>>
>>>
>>>
>>> ---------- Forwarded message ----------
>>> From: Ivan Junckes Filho <ivanjunckes_at_gmail.com>
>>> To: users_at_jax-rs-spec.java.net
>>> Cc:
>>> Date: Tue, 3 Jun 2014 21:01:07 -0300
>>> Subject: [jax-rs-spec users] Re: Hypermedia for structural links
>>> Thank you for the information Santiago.
>>>
>>> I will start looking at it and if I have something I let you know.
>>>
>>>
>>> On Mon, Jun 2, 2014 at 12:15 PM, Santiago Pericas-Geertsen
>>> <Santiago.PericasGeertsen_at_oracle.com> wrote:
>>>>
>>>> Hello Ivan,
>>>>
>>>> Yes, improving hypermedia is part of the plan. JSON-B will likely be an
>>>> addition to Java EE 8 as well, so we'll need to work with them on this.
>>>>
>>>> If you have any specific ideas or feedback on structural links in
>>>> particular, don't hesitate to send them to this or the expert's alias.
>>>>
>>>> Thanks.
>>>>
>>>> -- Santiago
>>>>
>>>> On Jun 2, 2014, at 9:05 AM, Ivan Junckes Filho <ivanjunckes_at_gmail.com>
>>>> wrote:
>>>>
>>>> > Hi guys!
>>>> >
>>>> > There is a lot of discussions around MVC and SSE right now, but one
>>>> > thing in my opinion that should be considered, and is very important to the
>>>> > JSR become more restful, is the standard implementation for hypermedia
>>>> > structural links.
>>>> >
>>>> > I would like to know your thoughts on that and if this could be added
>>>> > to jax-rs in a near future.
>>>> >
>>>> > Thank you.
>>>>
>>>
>>>
>>> End of digest for list users_at_jax-rs-spec.java.net - Wed, 04 Jun 2014
>>>
>>
>