|
http://in.geocities.com/rsramsam/jsf1.htm |
JAVA SERVER FACES
(JSF)
Published in
DeveloperIQ (APRIL-2005)
R.S.RAMASWAMY
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 technology
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,
text2.text=text1.text
Had this been a stand-alone Java program, the
code would have been,
text2.setText(text1.getText());
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.
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.
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, it 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 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.
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.(but this
requires JDK in client’s system..which is no problem in Intranet but we cannot
be sure in Internet clients)).
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 significant 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.
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.
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.
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!
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 at
all, 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).
In the second part of the tutorial, we will learn JSF fundamentals
by experimentation, intermixed with brief theoretical notes, where needed.
----------------------------------------
---------------------