3

Starting with JSF2.2, it is possible to write more elements in HTML5: writing <button> can be equivalent to writing <h:commandButton>.

But how does this work with other components libraries? Is it possible to override that behaviour and let <button> be translated to a component from some library other than the default/standard one (like <p:commandButton> from primefaces)?

From the documentation, I can see that a TagDecorator is needed but I don't see any in primefaces. Is it because primefaces has not (yet) implemented that feature or is it because JSF HTML5 friendly markup can generate standard components only (http://xmlns.jcp.org/jsf/html)?

Xavier Dury
  • 1,530
  • 1
  • 16
  • 23

1 Answers1

2

As you can see on the TagDecorator page you linked to, the 'html5 friendly' markup is only relevant to 'basic' inputs, buttons and links. PrimeFaces has some counterparts of these to, but if you take a closer look at the real advantage of this 'html5 friendly' notation, it mainly is on the design part. Why..

Take a look at these 3 examples:

  1. <input type="number" jsf:value="#{bean.value}"/>
  2. <p:inputText type="number" value="#{bean.value}"/>
  3. <h:inputText type="number" value="#{bean.value}"/> (http://balusc.blogspot.com.au/2012/06/adding-html5-attributes-to-standard-jsf.html)

The first one is html(5) friendly. But what 2 and 3 effively render on the client is dependend on the (in this case) shared implementation of the renderer (as can be seen in the tagDecorator page). What 1 renders is dependend on what PrimeFaces does. They could all render an <input type="number".../> on the client side, but they could also render something more complex (as PrimeFaces does now).

So what is the advantage of this makeup? Well as I see it, it was a 'counter action' to what all the Javascript frameworks and some other component frameworks like Tapestry advocated. That you can use plain html for page design. In my opinion this has only limited advantage. Many relevant ui component types like datatables, trees, menus, tabs and so on, need lots of javascript to work, add classes to the plain html and more to come close to what the page will eventually look like and hence they do not look good in the designer since all this css and stuff is missing. The same is true btw for complex jsf components, they do not render nice in the designer to and you still need the jsf 'tags' for them. So in the end, you'd mix plain html tags with their notation and 'normal' jsf, a combination that I tried and disliked (uniformity is good)

So all in all, I don't think it is strange that PF did not add TagHandlers to support this notation to their framework. I'd rather have them spend time and effort in further improving their components.

Kukeltje
  • 12,223
  • 4
  • 24
  • 47
  • 3
    Bravo! tl;dr: "HTML5 friendly markup" is only interesting when you intend to **manually** tie JSF together with client side frameworks like jQuery UI, Bootstrap, etc, rather than using a JSF component library already using those (PrimeFaces, BootsFaces, etc). Food for thought: http://stackoverflow.com/questions/4421839/what-is-the-need-of-jsf-when-ui-can-be-achieved-from-css-html-javascript-jquery – BalusC May 13 '15 at 22:11
  • @BalusC: Not that it matters (I can take a lot) But I'm not sure if there is any sarcasm in the Bravo! ;-) – Kukeltje May 14 '15 at 13:46
  • I was just delighted to see another one who wasn't made blind by all that HTML5 buzz. So there's indeed some sarcasm, but not targeted at you :) – BalusC May 14 '15 at 13:50