Skip to main content

Learning Java Server Faces

  • 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.


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

Planning a User Guide - Part 3/5 - Co-ordinate the Team

Photo by  Helloquence  on  Unsplash This is the third post in a series of five posts on how to plan a user guide. In the first post , I wrote about how to conduct an audience analysis and the second post discussed how to define the overall scope of the manual. Once the overall scope of the user guide is defined, the next step is to coordinate the team that will work on creating the manual. A typical team will consist of the following roles. Many of these roles will be fulfilled by freelancers since they are one-off or intermittent work engagements. At the end of the article, I have provided a list of websites where you can find good freelancers. Creative Artist You'll need to work with a creative artist to design the cover page and any other images for the user guide. Most small to mid-sized companies don't have a dedicated creative artist on their rolls. But that's not a problem. There are several freelancing websites where you can work with great creative ar

Inheritance vs. composition depending on how much is same and how much differs

I am reading the excellent Django book right now. In the 4th chapter on Django templates , there is an example of includes and inheritance in Django templates. Without going into details about Django templates, the include is very similar to composition where we can include the text of another template for evaluation. Inheritance in Django templates works in a way similar to object inheritance. Django templates can specify certain blocks which can be redefined in subtemplates. The subtemplates use the rest of the parent template as is. Now we have all learned that inheritance is used when we have a is-a relationship between classes, and composition is used when we have a contains-a relationship. This is absolutely right, but while reading about Django templates, I just realized another pattern in these relationships. This is really simple and perhaps many of you may have already have had this insight... We use inheritance when we want to allow reuse of the bulk of one object in other

Running your own one person company

Recently there was a post on PuneTech on mom's re-entering the IT work force after a break. Two of the biggest concerns mentioned were : Coping with vast advances (changes) in the IT landscape Balancing work and family responsibilities Since I have been running a one person company for a good amount of time, I suggested that as an option. In this post I will discuss various aspects of running a one person company. Advantages: You have full control of your time. You can choose to spend as much or as little time as you would like. There is also a good chance that you will be able to decide when you want to spend that time. You get to work on something that you enjoy doing. Tremendous work satisfaction. You have the option of working from home. Disadvantages: It can take a little while for the work to get set, so you may not be able to see revenues for some time. It takes a huge amount of discipline to work without a boss, and without deadlines. You will not get the benefits (insuranc