Adaptive Software Solutions

Here's how we build a simple JSF application: Configure web.xml for FacesServlvet Create faces-context.xml (This is the file from where FacesServlet reads navigation rules, details of managed beans and other JSF specific configuration details) Create a controller or controllers for the application. Here is where JSF differs from Struts. Struts had a front controller, the ActioServlet which delegated requests to Action classes. JSF does not have the notion of a front controller. A JSF application uses an event model. The UI is tied to the backend with events. Controller classes (also known as backing beans in JSF) accept these events and also hold properties that accept user supplied values from a form. These properties will also be used to display data on pages. For example if we have a simple application that allows employees to put in a leave request, a backing bean will have properties that will be populated with the request that the user enters on the form. The same backing bea...

The primary responsibility of a component is to decode and encode data. encode = convert request parameters to component attributes decode = render component attributes to the view (render html mostly...) The rendering can be directly implemented by the component or can be delegated to a renderer. We use a special renderer(s) when we want different types of rendering for that component (maybe for different display devices). So a JSF component has 2 parts: the component + renderer Image by Rick Hightower explaining on where rendering fits in the JSF lifecycle - Ref All custom components have to be subclasses of UIComponent. However, we subclass UICOmponentBase which is an abstract class that gives us a skeletal implementation of UIComponent. Creating the custom component: As an exercise, I will create a simple custom component that renders a 5x5 grid (as an html table). Here are the steps: Create a subclass of UIComponent (I chose UIOutput, since this is an output only component, ie. we...

Still reading Rick Hightower's article on JSF. This image has been referenced from Rick Hightower's article . The JSP page (essentially the tags) is bound to a server side view_root that maintains the state of the UI components. The view root is a composite just like Swing components. Any changes a user makes in their browser's view get reflected in the state of the view root. The view is also linked to properties (or nested properties) of a backing bean. It is recommended that we do not put business logic in the backing bean, they are meant to mediate between the view and the model. At first I thought, why do we need these backing beans? The properties can be set in the View Root objects, and they can handle the events as well, but I think there is a good reason for them. The View Root components are written by the component provider. We do not have control on them. However our application needs to have event handlers, and maybe transfer objects. These are bound to the v...

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