Jsf Vs HTML(Jsp) for Enterprise Portals UI Layer. Which One to Choose? and Why

Why do we need JSF tags , If we have HTML tags

JSF is a component based MVC framework which is built on top of the Servlet API and provides components in favor of taglibs, which can be used in JSP or any other Java based view technology such as Facelets. Facelets is much more suited to JSF than JSP. It namely provides great templating capabilities such as composite components, while JSP basically only offers the for templating, so that you're forced to create custom components with raw Java code (which is a bit opaque and a lot of tedious work in JSF) when you want to replace a repeated group of components with a single component. If you can, I recommend to drop JSP and go for Facelets when you want to develop with JSF.

As being a MVC (Model-View-Controller) framework, JSF provides the FacesServlet as the sole request-response Controller. It takes all the standard and tedious HTTP request/response work from your hands, such as gathering user input, validating/converting them, putting them in model objects, invoking actions and rendering the response. This way you end up with basically a JSP or Facelets (XHTML) page for View and a Javabean class as Model. The JSF components are been used to bind the view with the model (such as your ASP.NET web control does) and the FacesServlet uses the JSF component tree to do all the work.

JSF/Facelets: why is it not a good idea to mix JSF/Facelets with HTML tags?

During the JSF 1.0/1.1 ages this was indeed "not a good idea", because all the HTML was not automatically taken in the JSF component tree when using JSP as view technology. All plain HTML was eagerly by JSP rendered before the JSF component tree. E.g.

<p>Lorem ipsum <h:outputText value="#{bean.value1}"> dolor sit amet<p>
<p>Consectetur adipiscing <h:inputText value="#{bean.value2}" /> elit</p>

got rendered as

<p>Lorem ipsum dolor sit amet<p>
<p>Consectetur adipiscing elit</p>

value1
<input type="text" value="value2" />

To fix this you would need to bring <f:verbatim> in.

<f:verbatim><p>Lorem ipsum </f:verbatim><h:outputText value="#{bean.value1}"><f:verbatim> dolor sit amet<p></f:verbatim>
<f:verbatim><p>Consectetur adipiscing </f:verbatim><h:inputText value="#{bean.value2}" /><f:verbatim> elit</p></f:verbatim>

This was a real maintenance pain. This was one of the major reasons why JSF 1.0/1.1 was so hated.

Since JSF 1.2, with the new view handler, the <f:verbatim> was not necessary anymore. Developers can now breathe relieved. Moreover, the new view handler allowed JSF to use a different view technology than JSP and this way Facelets was born.

See also:

• What are the main disadvantages of Java Server Faces 2.0?
• Why Facelets is preferred over JSP as the view definition language from JSF2.0 onwards?
• Is it possible to use JSF+Facelets with HTML 4/5?
• JavaServer Faces 2.2 and HTML5 support, why is XHTML still being used

Mixing JSF Tag and HTML

This is not a bad practice. This is perfectly fine. The only reason to use a JSF component is to have access to it in the JSF component tree. It would be a more poor practice to use <h:panelGroup layout="block"> instead of <div> here. But if it was a container of which you'd like to ajax-update its content, then a <h:panelGroup id="foo" layout="block"> would have been perfectly fine as would an 'html5-friendly' <div jsf:id="foo"> with the xmlns:jsf="http://xmlns.jcp.org/jsf" namespace.

For a bit of history, you may find this useful: JSF vs HTML(JSP) for enterprise portals UI layer. Which one to Choose? and WHY?

The layout attribute is invalid according to the specified TLD

The layout attribute of <h:panelGroup> was introduced in JSF 1.2. This error suggests that you're using the ancient JSF 1.1 or perhaps even the dead JSF 1.0.

You have basically 2 options:

1. Upgrade to JSF 1.2 or preferably to JSF 2.x which is been out for over 2 years already and almost at version 2.2. You can download the JSF implementations here. Note that JSF 1.2 on JSP requires at least a Servlet 2.5 compatible container. So you need to have at least Tomcat version 6.0 or preferably Tomcat 7.0 which is been out for over 2 years already as well. Make sure that your web.xml is declared conform the highest servlet version supported by the container.

2. If you can't upgrade to JSF 1.2 or newer, because you're stuck to Tomcat 5.5 or older for some unclear reason, then you should forget using <h:panelGroup layout> and use a normal <div> element instead. You only need to wrap it in <f:verbatim> because JSF 1.1 and older cannot treat plain HTML normally.

   <f:verbatim><div></f:verbatim>
       ...
   <f:verbatim></div></f:verbatim>
   

See also:

• JSF vs HTML(JSP) for enterprise portals UI layer. Which one to Choose? and WHY?
• What are the main disadvantages of Java Server Faces 2.0?

Is it true that you must not use any plain HTML in RichFaces? Why?

You are right not to believe this. There is absolutely no problem in using plain HTML tags.

Facelets creates UIComponents even for static markup (i.e. non-JSF). It should just be valid.

Mixing JSF Tag and HTML

This is not a bad practice. This is perfectly fine. The only reason to use a JSF component is to have access to it in the JSF component tree. It would be a more poor practice to use <h:panelGroup layout="block"> instead of <div> here. But if it was a container of which you'd like to ajax-update its content, then a <h:panelGroup id="foo" layout="block"> would have been perfectly fine as would an 'html5-friendly' <div jsf:id="foo"> with the xmlns:jsf="http://xmlns.jcp.org/jsf" namespace.

For a bit of history, you may find this useful: JSF vs HTML(JSP) for enterprise portals UI layer. Which one to Choose? and WHY?

JSF or MVC with Servlets/JSPs or other frontend frameworks?

For a hobby webapp, homebrewing some MVC framework is not bad. It's a nice learning exercise tour. However, it will bite you on the long term, for sure if you publish on the web and it becomes popular. Most of existing MVC frameworks are very well thought out. Most of the unforeseen caveats are taken into account. The sole framework API is well maintained and documented by a third party.

Also, whenever your webapp becomes popular and you need more developers to work on it to fulfill the enduser requirements/wishes, it's easier to find someone who's already familiar with an existing framework. With a homebrewed and possibly buggy MVC framework, you'll likely find less developers who are eager enough to dive into another learning curve before taking over the maintenance which they'll probably never reapply on their future jobs/projects.

This does not specifically apply on JSF, but on every other existing and popular MVC framework as well, such as Spring MVC. As to JSF in general, well, I've written a lot about it before here. Here are some good starting points to read the one and other about it:

• JSF versus plain HTML/CSS/JS
• JSF adoption and popularity
• What are the disadvantages of JSF 2.0?

What are the main disadvantages of Java Server Faces 2.0?

JSF 2.0 disadvantages? Honestly, apart from the relative steep learning curve when you don't have a solid background knowledge about basic Web Development (HTML/CSS/JS, server side versus client side, etc) and the basic Java Servlet API (request/response/session, forwarding/redirecting, etc), no serious disadvantages comes to mind. JSF in its current release still needs to get rid of the negative image it gained during the early ages, during which there were several serious disadvantages.

JSF 1.0 (March 2004)

This was the initial release. It was cluttered with bugs in both the core and performance areas you don't want to know about. Your webapplication didn't always work as you'd intuitively expect. You as developer would run hard away crying.

JSF 1.1 (May 2004)

This was the bugfix release. The performance was still not much improved. There was also one major disadvantage: you can't inline HTML in the JSF page flawlessly. All plain vanilla HTML get rendered before the JSF component tree. You need to wrap all plain vanilla in <f:verbatim> tags so that they get included in the JSF component tree. Although this was as per the specification, this has received a lot of criticism. See also a.o. JSF/Facelets: why is it not a good idea to mix JSF/Facelets with HTML tags?

JSF 1.2 (May 2006)

This was the first release of the new JSF development team lead by Ryan Lubke. The new team did a lot of great work. There were also changes in the spec. The major change was the improvement of the view handling. This not only fully detached JSF from JSP, so one could use a different view technology than JSP, but it also allowed developers to inline plain vanilla HTML in the JSF page without hassling with <f:verbatim> tags. Another major focus of the new team was improving the performance. During the lifetime of the Sun JSF Reference Implementation 1.2 (which was codenamed Mojarra since build 1.2_08, around 2008), practically every build got shipped with (major) performance improvements next to the usual (minor) bugfixes.

The only serious disadvantage of JSF 1.x (including 1.2) is the lack of a scope in between the request and session scope, the so-called conversation scope. This forced developers to hassle with hidden input elements, unnecessary DB queries and/or abusing the session scope whenever one want to retain the initial model data in the subsequent request in order to successfully process validations, conversions, model changes and action invocations in the more complex webapplications. The pain could be softened by adopting a 3rd party library which retains the necessary data in the subsequent request like MyFaces Tomahawk <t:saveState> component, JBoss Seam conversation scope and MyFaces Orchestra conversation framework.

Another disadvantage for HTML/CSS purists is that JSF uses the colon : as ID separator character to ensure uniqueness of the HTML element id in the generated HTML output, especially when a component is reused more than once in the view (templating, iterating components, etc). Because this is an illegal character in CSS identifiers, you would need to use the \ to escape the colon in CSS selectors, resulting in ugly and odd-looking selectors like #formId\:fieldId {} or even #formId\3A fieldId {}. See also How to use JSF generated HTML element ID with colon ":" in CSS selectors? However, if you're not a purist, read also By default, JSF generates unusable ids, which are incompatible with css part of web standards.

Also, JSF 1.x didn't ship with Ajax facilities out of the box. Not really a technical disadvantage, but due to the Web 2.0 hype during that period, it became a functional disadvantage. Exadel was early to introduce Ajax4jsf, which was thoroughly developed during the years and became the core part of JBoss RichFaces component library. Another component libraries were shipped with builtin Ajax powers as well, the well known one being ICEfaces.

About halfway the JSF 1.2 lifetime, a new XML based view technology was introduced: Facelets. This offered enormous advantages above JSP, especially in the area of templating.

JSF 2.0 (June 2009)

This was the second major release, with Ajax as buzzword. There were a lot of technical and functional changes. JSP is replaced by Facelets as the default view technology and Facelets was expanded with capabilities to create custom components using pure XML (the so-called composite components). See also Why Facelets is preferred over JSP as the view definition language from JSF2.0 onwards?

Ajax powers were introduced in flavor of the <f:ajax> component which has much similarities with Ajax4jsf. Annotations and convention-over-configuration enhancements were introduced to kill the verbose faces-config.xml file as much as possible. Also, the default naming container ID separator character : became configurable, so HTML/CSS purists could breathe relieved. All you need to do is to define it as init-param in web.xml with the name javax.faces.SEPARATOR_CHAR and ensuring that you aren't using the character yourself anywhere in client ID's, such as -.

Last but not least, a new scope was introduced, the view scope. It eliminated another major JSF 1.x disadvantage as described before. You just declare the bean @ViewScoped to enable the conversation scope without hassling all ways to retain the data in subsequent (conversational) requests. A @ViewScoped bean will live as long as you're subsequently submitting and navigating to the same view (independently of the opened browser tab/window!), either synchronously or asynchronously (Ajax). See also Difference between View and Request scope in managed beans and How to choose the right bean scope?

Although practically all disadvantages of JSF 1.x were eliminated, there are JSF 2.0 specific bugs which might become a showstopper. The @ViewScoped fails in tag handlers due to a chicken-egg issue in partial state saving. This is fixed in JSF 2.2 and backported in Mojarra 2.1.18. Also passing custom attributes like the HTML5 data-xxx is not supported. This is fixed in JSF 2.2 by new passthrough elements/attributes feature. Further the JSF implementation Mojarra has its own set of issues. Relatively a lot of them are related to the sometimes unintuitive behaviour of <ui:repeat>, the new partial state saving implementation and the poorly implemented flash scope. Most of them are fixed in a Mojarra 2.2.x version.

Around the JSF 2.0 time, PrimeFaces was introduced, based on jQuery and jQuery UI. It became the most popular JSF component library.

JSF 2.2 (May 2013)

With the introduction of JSF 2.2, HTML5 was used as buzzword even though this was technically just supported in all older JSF versions. See also JavaServer Faces 2.2 and HTML5 support, why is XHTML still being used. Most important new JSF 2.2 feature is the support for custom component attributes, hereby opening a world of possibilities, such as custom tableless radio button groups.

Apart from implementation specific bugs and some "annoying little things" such as inability to inject an EJB in a validator/converter (already fixed in JSF 2.3), there are not really major disadvantages in the JSF 2.2 specification.

Component based MVC vs Request based MVC

Some may opt that the major disadvantage of JSF is that it allows very little fine-grained control over the generated HTML/CSS/JS. That's not JSF's own, that's just because it's a component based MVC framework, not a request (action) based MVC framework. If a high degree of controlling the HTML/CSS/JS is your major requirement when considering a MVC framework, then you should already not be looking at a component based MVC framework, but at a request based MVC framework like Spring MVC. You only need to take into account that you'll have to write all that HTML/CSS/JS boilerplate yourself. See also Difference between Request MVC and Component MVC.

See also:

• What is the difference between JSF, Servlet and JSP? (just to understand the basics)
• Using JSF to develop tableless CSS layouts (another myth about JSF)
• JSF vs plain HTML/CSS/JS/jQuery (when JSF is the wrong choice)
• Design patterns in web applications (illustrates the ideology behind MVC)

Alternatives to JSP for Spring MVC view layer

In the standard Java EE API, the only alternative to JSP is Facelets. As far now (2010) JSF is the only MVC framework which natively supports Facelets.

Spring MVC supports out of the box only JSP, but it has a configurable view resolver which allows you to use Facelets anyway. Other candiates are 3rd party templating frameworks such as Velocity, Freemarker, and Thymeleaf which can be configured as a view technology for Spring MVC. Spring documentation has integration examples with Velocity and Freemarker.

---

Related Topics