Hi,
On Wed, Jun 4, 2014 at 12:22 PM, Werner Keil <werner.keil_at_gmail.com> wrote:
> Comparing StackOverflow and JAXEnter (where the Vaadin numbers seem overly
> high, most others look representative)
>
Yes, I noticed that too. At JAXEnter the Vaadin number is suddenly off,
while for rebellabs it's SpringMVC.
If you don't look at the exact positions, but divide each outcome into say
three tiers; the top, middle and bottom tier, and just look at which
framework is in which tier but don't order them within the tier, then
results are mostly consistent.
> 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
> <http://docs.spring.io/spring/docs/4.0.x/spring-framework-reference/html/view.html>.
> You can also use Spring MVC with Facelets view technology
> <https://github.com/acichon89/springmvcfacelets>. 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 <http://jqueryui.com/>. It's also exactly
> what PrimeFaces >is using under the covers. PrimeFaces is a jQuery-based
> JSF component library.
>
It's my co-worker Bauke who said that ;) But indeed, it's the very topic
about which we had a lot of discussion even before the talks started here.
One aspect of the discussion is that when using Facelets supposedly
separately, you'll still be using components and JSF. Facelets uses
UIComponentBase which uses things like the FacesContext and other
infrastructure that has been set up by the FacesServlet.
An other aspect is that components actually DO work when using Spring MVC
with Facelets, but only the ones that render something and don't depend on
a postback. So practically Bauke is correct and giving any other answer
would only confuse people on SO, but technically it's more subtle than
that. There are indeed components that don't post anything back, like e.g.
h:panelGroup or p:graphicImage. We (Bauke and I among others) build the
public part of
http://m4n.nl in that way; it uses Facelets for view
compositing and components, but no components that postback anything.
The way that JSF handles a postback is that it executes the same algorithm
that was used to render the view. Because the algorithm is deterministic,
the exact same tree and IDs will be generated and those will be matched to
the POST data to see which component exactly has submitted something (e.g.
which button inside a nested table was clicked).
This specific was of working has a major advantage, and that's that you
have a kind of automatic protection against things like the mass assignment
vulnerability of RoR; JSF will only process the data that was actually
rendered. This automatic correlation is not there in pure action oriented
frameworks.
The downside is that the view thus needs to be available for processing the
submitted data, and that there are concerns about the memory and cpu
resource drain involved with that. While this may be an issue to some
degree, I saw some interesting research from Leonardo where despite not
needing the original view to process postbacks, Spring MVC still put more
pressure on the garbage collector. See
http://www.jsfcentral.com/articles/understanding_jsf_performance_3.html
But the fact that the view needs to be available is the biggest challenge
of making JSF compatible with action oriented concepts for the postback.
The initial GET is no problem at all, and is already done in a kind of
hybrid way by today's view action and in a more pure action oriented way by
both Manfred's and Leonardo's prototypes (and in fact by a prototype I
experimented with myself some time ago but never published)
> 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;-)
>
For sure. The concept of JSF being a spec having multiple implementations
and related projects doesn't exactly fits their model. Mojarra, MyFaces,
PrimeFaces, Richfaces are all listed as individual web frameworks which
indeed isn't right. It's a mistake I've seen at a couple of other places in
the past as well.
Kind regards,
Arjan Tijms