JSF Tutorial for Beginners

JAVA SERVER FACES ( not to be confused with JSP..JAVA SERVER PAGES), is the latest technolgy from JCP(Java Community Process).

JSF Tutorial for Beginners


([email protected])

published in DeveloperIQ

JSF Home | PART-1 | PART-2 | PART-3

     JAVA SERVER FACES ( not to be confused with JSP..JAVA SERVER PAGES), is the latest technolgy from JCP(Java Community Process).

It is  a technology that can be used instead of Struts or along with Struts,during the transition phase.   In this three  part  tutorial, the author gives the salient features of the technology with  a simple  illustration.


   JAVA SERVER FACES is  the equivalent of ASP.Net's web-forms technology, with something more in features and something less in elegance and ease. JSF 1.0 was released in March, 2004 & a maintenance release 1.1 in June, 2004. So, it is quite recent. It has the backing from all the big players in J2EE field, like SUN,IBM,ORACLE,WEBLOGIC,BORLAND &   APACHE. 

Craig MacLanahan, employed in SUN and   the main contributor behind Struts , is the lead architect of JSF. He maintains that JSF is a supporting technolgy for Struts and not necessarily a replacing technology. He himself has suggested a method of integrating Struts with JSF and getting the best of both worlds.

( As this tutorial presumes a foundation in Struts, readers will do well to refer to the tutorial on Struts in DeveloperIQ..Jan2005).

However, many analysts and authors are of the opinion that JSF is a definite improvement over Struts.Thus, it may be expected that quite a few applications in Industry , presently using Struts may switch over to JSF in the near future. In a few special cases, combining both JSF & Struts may be attempted, in order to maintain backward compatibility, during the transition phase.What is worth noting is that, transition is inevitable.

From the view-point of productivity, builder tools  are preferred by the Industry.

For example, though, we can build very elegant and powerful applications in ASP.net , by using only a text-editor , Industry prefers to use Visual Studio  , because of the number of advanced features like 'Intelli-sense', class browser etc.Similarly, while a considerable number of programmers prefer to use nothing but JDK and related libraries with text-editors , however complex the code might be,equally numerous programmers prefer to use the visual tools like JBuilder, JDeveloper and IBM's WebSphere Studio.

The only problem is that while JDK is a single entity and hopefully can be mastered, builder tools are numerous and one cannot be equally productive in all the tools. Thus, anyone , who makes extensive use of such tools in his work, gets habitually  tied to that tool and becomes much less productive in another environment. And for students and job-seekers, this poses a problem , since, with all their proficiency is a particular builer-tool like '(say) Eclipse, the employer may be a fan of some other tool such as 'JDeveloper'.

Such a problem does not occur in Microsoft Visual Studio, because there is one and only Studio. But even in Microsoft IDE, there are

possibilities for working in various types of projects. Even the VC++ studio, offers options for console mode,win32 apps,Wizard-based  dialog mode, SDI , MDI etc.Thus , if we want, we can develop our program without using wizards and code-generators thereby greatly reducing the number of files and code-bloat.

It is a moot point, how advisable it is to learn java programming through an IDE! Ultimately, we have JDeveloper Java, JBuilder Java, Eclipse Java ,IdeaJ Java  and so on.The spam wars going on, in the web between the respective  camps ,is testimony to this splintering!

That said, Industry is not prepared to forego the enormous increase in productivity offered by these tools. Thus learners have to master atleast two or three leading Java-IDE environments besides the  plain JDK, to feel at home in Industrial environment and trust their luck to land in a java shop that uses an IDE known to them! That pinpoints the necessity for standards.JSF is such a standard.

JSF is a specification, to which  big companies like Borland , WebLogic, Oracle, SUN etc can offer Studio like tools to enhance productivity. And , they have already adopted and introduced JSF in their tools. Added to this is the advantage that it comes from JCP and that settles the issue, for good! .Hence JSF is inescapable area of expertise for Java developers.

 Just as we can build asp.net pages by hand-coding, we can build JSF also by hand-coding. But , the main advantage as perceived by many analysts is that JSF being a specification, it has created a common standard for Visual Builder tools for web-application development in Java. As it is backed by all the big players, it is bound to gain momentum and universal acceptance quickly.

The problems that are addressed by Struts are different from those addressed by JSF. Struts is a framework based on MVC and it provides a ready-made structure, the main advantage being, DECLARATIVE MANAGEMENT in two important  files, namely, web.xml and struts-config.xml. Secondly, it provides the concept of form-beans and centralized flow through the Controller servlet and respective action classes. It separates the view (JSP) and the model (business logic).It has been widely adopted by the industry and has proved its worth.

Why then, JSF?  Unlike Struts, JSF is not a web-application framework but  was intended primarily, to be a User-interface technology, for web-based applications. In this aspect, it is exactly like ASP.net's WebForms.However, it soon grew out of this constraint and overlapped with much functionality and architecture of Struts.


Let us now  consider a simple example.

  Let there be a  form with two text boxes and a button. When the user types his name  in text1 and clicks the button, it should appear in text2.

   In VB, we would have written,


   Had this been a stand-alone Java program, the code would have been,



But how do we do this in a web-application? 0

In desktop applications, the variables are readily available in the program's memory space. But in web applications, HTTP is used and it is state-less. So, we can only collect the data typed in text1, in the server-side.

 After this , we have to dynamically create the same gui as before and populate the two textboxes, in the client's browser,and send the button too! Struts solves this problem, by creating a form-bean ..It would be nice if java web-application developers are 'made to feel' that they are  working in a Swing based Applet , instead of web-based html form with all its 'forgetfulness'!That is precisely the problem tackled by JSF.

For all appearances, it is as if the program works as in desktop application, where when we click a button(ActionEvent), make a change in textbox(TextEvent),make a selection in combo(ItemEvent),there is a reaction at component level .Struts, for all its advanced features, lacks this, as it is a page-level technology. 1

JSF , being a component-level technology , tries to mimic a desktop application.We can imagine that the form with all its controls and data is saved and sent back to the browser in ASP.net and JSF , whereas, in traditional ASP & jsp, is is only the data that is accepted by the webserver and the gui has to be dynamically created again!The 'component tree' is   said to be sent to the server and sent back to the browser as a hidden data , from which the original gui is 're-created'. 

A comparison of a simple program in VB,ASP & ASP.net, would bring out this aspect clearly.

Or if we prefer, we can think of a Java  desktop program, JSP ( either plain,or MVC or Struts) and JSF.If we combine the features of VB & ASP, we get ASP.net. (we are speaking here of how it 'appears' to the developer, and not as it is implemented!).Similarly, when we combine Desktop Java & Struts, we get JSF. 2

Clearly then , JSF is an advance over Struts, with the added advantage of being an official JCP standard, unlike Struts.

 About ten years back(1995), users were captivated by the tremendous reach and ease of Web-based applications. They used to call those start-ups as 'click & barter' company in the place of  'brick & mortar' company. Even today, there are hugely successful

 e-commerce companies like Amazon.com. So, the web-based business model is here to stay and grow. There is no going back to narrow lan(e)s of pre-web days. 3

But, as  business grows, developers and users alike, want to have all the ease, color, variety and user-interaction of a desktop application like VB ,in a web-based form! Surprisingly, was it not offered by Java Applet, in its very first month? But, it was objected that the business logic was done by the applet in the client's browser and except for very simple applications, downloading all those heavy classes   from the server into the client's browser is not at all a good solution.

 Later, Sun came out with Servlets solution, in which the business logic is executed either in web-server or in the next tier of application server(RMI-style).And it is possible to send data to the servlet , not through the html form but through an applet.(They used to call it Applet-Servlet Communication and Tunnel method).

If that is the case, the rich user-interface of applets can be combined with the power of a servlet and since the applet is used only for attractive user-interface and quick user-interaction, there could be no objection. The client's machine need not have JDK installed. The applet can be downloaded from server. This approach had an added advantage too. By suitable relaxation of security policy, data can be extracted from the hard-disk of the user by the applet and sent to the servlet. Similarly, the result sent by the servlet to the applet can be stored in the user's hard disk.Thus,  we can save the data in a textbox to the file in hard disk, elegantly.That is the power of Component approach over page approach. 4

Though, the first wave of books and literature on Servlets (1999)always spoke about servlet-applet communication, it fell out of favor, possibly due to the rift between Microsoft and Sun for fear that the almost universal Internet Browser and even Netscape Navigator, did not implement JDK fully in those days. And Swing is not implemented in these browsers directly , even today. It is only by using Java plug-in from Sun, we can view Swing applets in browsers.In J2EE field, where innovations and changes are occuring almost every month, a timelag of half a decade is equivalent to 'anachronism'.

There is not much use in connecting a servlet through a stand-alone frame. We cannot go about distributing the client-side classes to the users.Only if it could be downloaded from the server, it can serve a vast clientele.It is signigicant that the Applet technology has no equivalent in Microsoft technologies, to this day! Applets do not get installed in the user's machine but if AciveX controls embedded in html were downloaded , they got registered in the Windows Registry.

 ActiveX Documents tried by Microsoft , were not html forms and so could not be a standard method. That is what led them to develop ASP.net web forms.(please refer to a tutorial on ASP.net in  DeveloperIQ...Feb --2004).But, still, the web-form controls are not the same as windows-form controls. DataGrid of windows-forms in Dotnet and DataGrid in Web-forms , will show this difference.Thus, it would appear that if it were possible to ressurect the Applet-Servlet approach, it would be incomparable, in effect. 5

  Now that Sun & Microsoft have buried the hatchet and agreed to co-operate for the coming decade, it will not be too much to expect Microsoft to implement jdk fully in its browser, atleast so far as Swing GUI goes.  If that happens, we can combine all the advanced gui features of Swing applets with the power of Servlets/JSP. .

In the absence of response to this wish-list, the next best solution is to create controls in server-side and somehow send it to the browser, as html. That is what is being done by ASP.net & JSF.

We just forget that we are working in web-browser! Instead of complex session-tracking, we have the concept of 'sticky controls'(ie) any data placed in controls, retains the value , even after being submitted to the web-server. 6

Round trip to the server is inevitable in a web application. True! But, the technolgy should hide all that complexity and make the coder feel that he is developing a desktop application. This is the chief merit of ASP.net's WebForm and also that of JSF.

How then does JSF differ from ASP.net? There is no concept of Declarative management in ASP.net, exactly matching that in JSF. But the plus point of ASP.net webforms is that naming of the tags is much  like standard html tags ( or VB)  and elegant, unlike the JSF tags.Many more comparisons could be made but the main thrust of this tutorial is getting acquainted with JSF and so such a comparative evaluation, will have to wait. It is well to remember that  there is no place for Talibanism in Technology!Discerning observers can easily see how each camp is learning from the other and trying to do one better.That is how progress takes place.

Just because, we said that JSF is primarily a GUI technology for web-applications, it should not be taken to mean that it does away with all that concern about MVC Architecture. 7

That would have been a step back, after so much  work  that has been done to achieve separation of Model,Controller & View. Thus, JSF adopts quite a few features from Struts. For example, here also there is a central controller servlet , only, it is named Faces Servlet. Here also, we have, a configuaration-file like Struts-config.xml, but it is now faces-config.xml

Decalative navigation method also has been adopted. Just as in Struts, the code simply returns 'Success' or 'Failure' and the resulting forwarding is decided declaratively by Navigation rules in the xml file. Internationalization, Error messages, Validations, beans for holding data, model beans etc are all very much in the same style of Struts.

We have custom tags in JSF too.( And these tags may not always be compatible with JSTL!). ... And many of these html tags had no equivalent in JSTL. There is overlapping functionality and nomenclature between JSF tags and Struts tags. While, Struts used JSP EL(Expression language), JSF uses JSF EL! 8

Thus, JSF may be looked at as an 'improved' Struts . Many authors feel that JSF is easier to implement and richer in user-functionality,but Struts validation is said to be much better. However,things could improve  in the coming months.

While Struts is strongly tied to standard browsers, JSF caters to all kinds of emerging browsers like wap-browsers and wireless devices, just like ASP.net. As wireless is the emerging trend, this also is a progressive step in JSF.At the pace in which wireless communication infrastructure and technologies are being developed all over the world, purely desktop wizardry has no value atall, in future. The real challenge is to develop a web-application with the look and feel of the desktop application!It takes some effort to effect this change in approach. 

What JSF brings  to the party is ,the direct Event model , like Swing's Action event and ActionListeners,a concept like  Container for controls in Swing, etc. 9

( 'Mastering Java Server Faces' by Bill Dudney & others..Wiley/DreamTech.. makes a detailed comparative study of Swing/Struts/JSF approach and is instructive).

 In the second part of the tutorial, we will learn JSF fundamentals by experimentation, intermixed with brief theoretical notes, where needed.

---------------------------------------- 0

  PART-1 | PART-2 | PART-3