JSF 2.2 – Java Server Faces : UI Components
- JSF UI Components
- Key Components of JSF
- Directory Structure of JSF Projects
- Downloads Example
- How It Works
| JSF UI Components |
The basic point is that
- The model can consist of plain old Java objects (POJOs), EJBs, or something else.
- The view can be JSPs or some other display technology.
- The controller is always implemented as a servlet.
| Key Components of JSF |
Key Components of JSF includes elements of JSF which includes the following:
- UI Component
- Renderer
- Validator
- Backing Bean
- Converter
- Events and Listeners
- Messages
- Navigation
UI component:
A Stateful Object maintained on the server which provides a specific functionality for interacting with the user.
UI components are the centerpiece of JSF and are used as building blocks to create user interfaces that range from simple to complex. JSF provides a standard user interface component framework for the Web. Every user interface component in JSF implements the javax.faces.component.UIComponent interface.
Renderer:
Displays a UI Component and translate user inputs into its values.
Rendering:
One of the most important aspects of user interfaces is how they look and feel to users. JSF provides a flexible mechanism for rendering responses in Web applications, and it comes in two forms: direct rendering within a user interface component and delegated rendering via Render Kits that occur outside of a user interface component.
Validator:
Ensures that the value entered by the user is valid or acceptable.
Validation:
Performing correctness checks on user-submitted data is an important aspect of all applications that collect information. Validation in JSF comes in two forms: direct validation within a UIInput component and delegated validation, which occurs outside of a UIInput component.
Direct Validation:
If your validation is specific to a particular UIInput component, then you may implement your validation code within the component by overriding the validate ( ) method. At the appropriate point in the request processing life cycle, the JSF framework will invoke this method, thereby executing any code you have provided for correctness checking. This method of validation provides a quick and efficient means of validating your components; the downside is that your validation code is not portable. An additional restriction is that you can only use this method of validation for your own components or you must subclass an existing component to implement validate ( ) method.
Delegated Validation:
If your validation should be reused among different user interface component types or if you would like to attach a certain type of validation to an existing component, the JSF framework provides two useful mechanisms: validate method binding and Validator components. The method binding mechanism allows you to delegate component validation to a method on any managed bean or JavaBean in scope. It is similar to direct validation in that you are associating validation logic directly to a UIInput component.
Standard Validators:
A summary of each standard Validator is provided in Table.
Backing Bean:
Collects values from UI Components and implements event listeners
We discussed the Model-View-Controller (MVC) design pattern and how it separates an application into its corresponding model, view, and controller layers. Model consists of application logic and data, the view consists of the UI, and the controller defines the interaction between the two.
Backing Beans are merely a convention, a subtype of JSF Managed Beans which have a very particular purpose. There is nothing special in a Backing Bean that makes it different from any other managed bean apart from its usage.
JavaBean objects managed by a JSF implementation are called managed beans. A managed bean describes how a bean is created and managed. It has nothing to do with the bean’s functionalities.
Backing beans are JavaBeans components associated with UI components used in a page. Backing-bean management separates the definition of UI component objects from objects that perform application-specific processing and hold data.
| Backing Beans | Managed Beans |
|---|---|
| A backing bean is any bean that is referenced by a form. | A managed bean is a backing bean that has been registered with JSF (in faces-config.xml) and it automatically created (and optionally initialized) by JSF when it is needed. The advantage of managed beans is that the JSF framework will automatically create these beans, optionally initialize them with parameters you specify in faces-config.xml, |
| Backing Beans should be defined only in the request scope | The managed beans that are created by JSF can be stored within the request, session, or application scopes |
Converter:
Converts a component value to and from string for displaying.
When users interact with a JSF application, they interact with the output of renderers, which create specific representations that make sense for a particular client (like a Web browser). In order to do this, renderers must have specific knowledge about the components they display. But components can also be associated with backing bean properties.
Events and Listeners:
UI Components generate events and listeners will handle those events.
For UIs, events capture the way the user interacts with UI components. An event could be something like simply clicking on a component or it could be more complicated, such as executing a specific command.
Messages:
Information like error messages displayed back to the user. One of the biggest issues when developing a UI is properly displaying error messages.
Messages are categorized into two.
Application errors (business logic, database, or connection errors, for example) User input errors (such as invalid text or empty fields).
Application errors usually generate a completely different page with the error message on it. Input errors usually redisplay the calling page with text describing the errors.
Navigation:
Selects the response page to be displayed.
Web applications have multiple pages, and you must have some way to move between them. The act of moving from one page to another is called navigation.
Faces have a pretty elegant navigation system. The navigation handler is responsible for deciding what page to load based on the logical outcome of an action method. For any given page, a navigation rule defines what outcomes are understood, and what pages to load based on those outcomes.
| Directory Structure of JSF Projects |
Directory Structure
JSF applications are standard Java Web applications. Hence all the necessary files must be packaged in a directory structure that is to be deployed in a Web container. It uses the same directory structure as that of a normal Web application. The figure shows the directory structure of a JSF application.
The above figure- shows the detailed directory structure of a sample JSF application named JSFDemo
The WAR file typically has this directory structure:
index.html
JSP pages
WEB-INF/
-web.xml
-faces-config.xml
-tag library descriptors (optional)
-classes/
-class files
-properties files
-lib/
-JSF JAR files
-JSTL JAR files
-Application JAR files
All of the elements in this file are nested under the <faces-config> element as above.
| Downloads Example |
Click the below Link to download complete Library
| How It Works |
How It Works:
1. When the user access the application using the following URL http://hostName:port/Webappname/index.faces. the browser displays the index page with two text boxes and a button.
2. As it encounters <h:inputText class=”nname” value=”#{userBean.name}” /> it search for a userBean instance in request, session, application scopes.
3. If it finds one, then it will display the value of the name property in the text box.
4. If it does not find one, then it search for a userBean entry in faces-config.xml and creates a new userBean instance with the specified class and stores it in the specified scope.
5. Now the name property will also be null and the text box will be blank. Similarly the age too.
6. Once the user types his name, age and clicks the button (form submission or post back), the value entered in text boxes will be stored in userBean properties name, age.
7. It then takes the action attribute value and search for a match in faces-config.xml and navigates to welcome.jsp.
8. The browser renders the welcome.jsp page.
9. When it encounters this line, <h:outputText value=”Welcome #{userBean.name}” /> it gets the value of name property of userBean and displays. Similarly it displays age also.
10. To conclude, during form submission JSF invokes the setter methods of bean and during rendering the getter methods of bean will be invoked.
11. While displaying the details to the user, JSF invokes the setter methods of bean when the form is submitted through the button click. And similarly during rendering, the getter methods of the bean will be displayed.
Recent Comments