Skip to main content

Learning Java Server Faces

Resources:
  • Marty Hall has a good JSF tutorial here.
  • Rick Hightower has a very good 4 part series on JSF here.

Reading the first part of Rick's tutorial.

JSF provides component tags for every input field available in standard HTML. [Ref]

Well I guess, JSTL also did this.

JSF components are stateful. The statefulness of the components is provided through the JSF framework. JSF uses components to produce HTML responses.
Were JSP tags also stateful? No. Assuming we are using Struts, let's say we change the state of a form, the state change is transmitted to the backend as an HTTP request. This causes some bean properties to be set. The original form can now be displayed again, using the form bean as a a source for the state of the form. This form will reflect the new change as long as form bean is accessible to the JSP tag. So the state is saved in the form bean, and the fact that the form bean is made accessible to the Tag helps us manage the state of the UI.
In JSF, I believe the state of the view is saved in a corresponding server side component [need to check this].

JSF's component set includes an event publishing model
This is a big change from Struts and the earlier frameworks. However, I remember reading somewhere, that JSF apps do not support plain old GET requests (links). Could this be because of the event based approach? [need to check this]

The JSF framework also has:
  • A lightweight IoC container
  • Server side validation
  • Data conversion

JSF and JSP:


JSF uses JSP as the UI rendering technology (not quite, but read along...)

Each JSP page contains JSF components that represent the GUI functionality. You use JSF custom tag libraries inside JSP pages to render the UI components, to register event handlers, to associate components with validators, to associate components with data converters, and more

I am not sure about the rendering part. From what I understand the JSP pages are used because they support tags. JSF tags create a representation of the component on the server. This representation saves the state of the component, and certain server side classes are responsible for rendering the component as well. So the JSP seems to be used simply because it supports tags. That said, it is possible to use other technologies for the UI, such as Facelets and xml namespaces (instead of tags). One implication of this, is that if a JSP page is changed and dropped into the server, the server will not reflect the changes if the server side component representation has already been created. This is because JSP is not used for rendedring, but simply to set up a server side component tree to represent every component coded in the view with JSF tags. Rick does go on to breifly explain this.

JSF and MVC:
The main complaint against Struts is that it can feel more procedural than object-oriented
Hmmm this may be true, but it was to accomodate the (stateless) HTTP protocol. True JSF does seem more OO because it abstracts the web behind a component based model. But it still has to be seen how well the creases are ironed out. It is still premature to say that JSF's component based model is superior (because it is less procedural... use the methodology that is best suited for the job... and it is possible that the procedural methodology might just be better suited to accomodate a stateless protocol... ).

JSF offers a richer MVC environment:

That does seem to be true. User interactions on the UI are transmitted to the backend as events, whereas in Struts they are request parameters. Are events better than request parameters? They surely are more OO. Maybe they are better, but there could be a downside. Many applications need support for link based entry points. For example when someone tries to connect to a LinkedIn member, the application sends the member links to approve the request ot reject the request. This works because we have not abstracted the underlying protocol. Would this work just as well in a JSF application? I do not think so, because a JSF backend needs events, and events cannot be generated when a user clicks on a link from their mail client. I am sure there is a workaround though.

JSF's fine-tuned event model allows your applications to be less tied to HTTP details and simplifies your development effort.
I am not sure. Maybe writing simple CRUD applications will become much simpler, but writing complex applications might become significantly more difficult.

SF also improves somewhat on the traditional Model 2 architecture by making it easier to move presentation and business logic out of your controller
I don't believe either presentation or business logic was in the controller in traditional model 2 apps. Though people did put business logic in the view (JSP pages), and I agree that JSF makes that more difficult (because the view is rendered from a server side component model, so it is difficult to mix html with tags on the view pages in the JSP's).


Unlike a true MVC architecture it is unlikely that the JSF model tier is issuing many events that have to be resolved in more than one viewport;
True. Though if we need this, remoting [link] does give us the capability.

Comments

Anonymous said…
Link clicks can't be seen as events?

I created my own web framework and clicks were events. What is worng with that?
Anonymous said…
To rephrase myself: What is wrong with that? (beyond the misspelling :-)

By the way JSF is very slow when compared with my web framework because I used only one JSF component that contained all components inside itself... So the JSP was very short and compiled quickly.

Also JSF doesn't seem to be able to handle the onPaint event.

Talk about an immature web framework.

Popular posts from this blog

My HSQLDB schema inspection story

This is a simple story of my need to inspect the schema of an HSQLDB database for a participar FOREIGN KEY, and the interesting things I had to do to actually inspect it. I am using an HSQLDB 1.8 database in one of my web applications. The application has been developed using the Play framework , which by default uses JPA and Hibernate . A few days back, I wanted to inspect the schema which Hibernate had created for one of my model objects. I started the HSQLDB database on my local machine, and then started the database manager with the following command java -cp ./hsqldb-1.8.0.7.jar org.hsqldb.util.DatabaseManagerSwing When I tried the view the schema of my table, it showed me the columns and column types on that table, but it did not show me columns were FOREIGN KEYs. Image 1: Table schema as shown by HSQLDB's database manager I decided to search on StackOverflow and find out how I could view the full schema of the table in question. I got a few hints, and they all pointed to

Commenting your code

Comments are an integral part of any program, even though they do not contribute to the logic. Appropriate comments add to the maintainability of a software. I have heard developers complain about not remembering the logic of some code they wrote a few months back. Can you imagine how difficult it can be to understand programs written by others, when we sometimes find it hard to understand our own code. It is a nightmare to maintain programs that are not appropriately commented. Java classes should contain comments at various levels. There are two types of comments; implementation comments and documentation comments. Implementation comments usually explain design desicisions, or a particularly intricate peice of code. If you find the need to make a lot of implementation comments, then it may signal overly complex code. Documentation comments usually describe the API of a program, they are meant for developers who are going to use your classes. All classes, methods and variables

Fuctional Programming Principles in Scala - Getting Started

Sometime back I registered for the Functional Programming Principles in Scala , on Coursera. I have been meaning to learn Scala from a while, but have been putting it on the back burner because of other commitments. But  when I saw this course being offered by Martin Odersky, on Coursera , I just had to enroll in it. This course is a 7 week course. I will blog my learning experience and notes here for the next seven weeks (well actually six, since the course started on Sept 18th). The first step was to install the required tools: JDK - Since this is my work machine, I already have a couple of JDK's installed SBT - SBT is the Scala Build Tool. Even though I have not looked into it in detail, it seems like a replacement for Maven. I am sure we will use it for several things, however upto now I only know about two uses for it - to submit assignments (which must be a feature added by the course team), and to start the Scala console. Installed sbt from here , and added the path