JAVA SERVER FACES ( not to be confused with JSP..JAVA SERVER PAGES), is the latest technolgy from JCP(Java Community Process).JAVA SERVER FACES ( not to be confused with JSP..JAVA SERVER PAGES), is the latest technolgy from JCP(Java Community Process).
INTRODUCING JAVA SERVER FACES (JSF)
published in DeveloperIQ
SERVER FACES ( not to be confused with JSP..JAVA SERVER PAGES), is
the latest technolgy from JCP(Java Community Process).
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
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
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
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
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.
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
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?
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.
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.
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.
Clearly then , JSF
is an advance over Struts, with the added
advantage of being an official JCP standard, unlike
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
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.
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.
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.
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.
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.
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.
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
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.
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
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!
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
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.
( 'Mastering Java
Server Faces' by Bill Dudney & others..Wiley/DreamTech.. makes a
detailed comparative study of Swing/Struts/JSF approach and is instructive).
the second part of the tutorial, we will learn JSF fundamentals by
experimentation, intermixed with brief theoretical notes, where