what is jsf and jsp?
The key idea to a framework like JSF is to encapsulate (or wrap) client-side technologies like HTML, CSS, and JavaScript, allowing developers to build web interfaces without much interaction with these technologies.
This article presents a snapshot of JSF's approach to component-based UI development for Java web applications. Simple examples introduce JSF's MVC architecture, event model, and component library. Examples include new features in JSF 2.3, and we'll use PrimeFaces for our component library.
Long popular, JSF has recently faced competition from Java-compatible web frameworks, including client-side JavaScript frameworks. Still, JavaServer Faces remains the Java standard, especially for large-scale, Java enterprise development. The JSF specification has also spawned a wealth of frameworks and libraries, which have kept pace with recent client-side improvements. One of these is PrimeFaces, which we explore in this tutorial.
While the schedule for future development is unclear, JSF 2.3 gives developers plenty to work with while we wait. Released in March 2017, JSF 2.3 was intentionally designed to modernize JSF. Among several hundred small repairs and larger updates, JSF 2.3 deprecates managed bean annotations in favor of CDI, which I'll introduce later in this tutorial.
JSF's core idea is to encapsulate functionality into reusable components. This is similar to the reusable tags used in JSP, but JSF components are more formal.
While you can use JSF pages within JavaServer Pages, it's more common to use Facelets to build standalone JSF pages. Facelets are XHTML pages designed for defining JSF interfaces. With Facelets, you use XML tags to create a component tree that becomes the scaffold for a JSF user interface.
Listing 1 presents the main parts of a simple JSF page written using Facelets. In this example we're accessing Java's server-side capabilities via a bean that's been placed in scope via CDI. You'll see more about CDI later on.
In Listing 1 we see a standard XHTML page. A Facelets view is built on top of XHTML. In addition to the XHTML namespace, a secondary namespace is defined and referenced.
The h library contains standard components for use in JSF HTML pages. The http://xmlns.jcp.org/jsf/html library defines a collection of JSF components, in this case a collection of common HTML elements. One of these components is the
In terms of syntax, Listing 1's
The
Inside the head is nested a standard HTML
In the body of the doc, a JSF expression is contained by the #{} syntax. This is exactly analogous to a JSP expression with the ${} format: it allows the access of Java objects in scope, and simple functions.
The basic pattern for JSF is simple: Use Facelets to build an XML tree that references a component library or libraries, then use components within the library to render Java objects as HTML.
Going back to Listing 1, notice that inside the JSF expression (${javaBean.content) The javaBean object is in scope when this markup is executed. The XHTML of Facelets accesses the .content property on the javaBean object. The final output is a web interface that merges the Facelets view structure with Java's server-side data and logic capabilities.
Using a JSF expression is just one way to access Java application data from a JSF user interface. Eventually, you'll want to explore other ways a JSF component can interact with the Java backend--things like data lists and grids and a variety of input controls. For now, it's enough to absorb how JSF uses XML tags (or annotations) to create a tree of components that outputs HTML based on the data contained in Java objects.
Like JavaServer Pages and the Servlet API, JavaServer Faces requires a standard directory structure and metadata. These are deployed as .war files.
The structure of a .war file is similar to a Servlet or JSP application. It contains a /web-app directory, which holds the application's markup files (in this case HTML, JSP, and Facelets), as well as a /WEB-INF directory, which presents the metadata to describe the application.
One of Java's strengths is that it is standards based, and those standards are governed by an open source community process. Since its inception, the Java Community Process (JCP) has overseen the development of Java technology. Once a specification or specification improvement has been developed and approved by JCP, it is available to be implemented by multiple parties. Until recently, Servlets, JSP, and JSF were all developed using JCP's open source specification process.
The most recent JSF specification as of this writing is JSF 2.3, released as part of Java EE 8 in 2017. Oracle's (now Eclipse's) Mojarra is the JSF reference implementation, and MyFaces and PrimeFaces are popular third-party implementations.
Each of these frameworks implements the JSF core, which includes some standard components. Vendors may also offer additional component libraries on top of the standard. When evaluating JSF frameworks, it's a good idea to consider the needs of your application and what component libraries are available to help you build it. Ideally, your JSF framework should get you as close as possible to what you need, right out of the box.
JSF is an MVC framework, implementing the model-view-controller pattern. In the MVC pattern, the idea is to separate the three concerns of a UI into discreet parts, so they're easier to manage. In general, the view is responsible for displaying data in the model, and the controller is responsible for setting up the model and routing the user to the correct view.
In a JSF implementation, the view is the Facelets page with its set of XML tags. These define the layout of the user interface. The other half of using JSF is the server-side, where Java classes back those UI components.
In JSF 2.3, controller beans provide the controller part of the MVC equation. Normal Java objects (often called POJOs, or plain old Java objects) provide the model.
In terms of process flow, controller beans:
JSF then folds together the component tree and model to render the output HTML.
Listing 2 shows how you would define the javaBean object from Listing 1 using CDI. This listing assumes the application has the cdi-api-1.2.jar in its dependencies.
In the next sections I'll use PrimeFaces to show you how JSF implements the MVC pattern, event-driven messaging, and reusable components. To start, open up the PrimeFaces Showcase, click the Data link in the left-side column, and select DataList. This will pull up the DataList demo code for PrimeFaces.
Figure 1 shows you where to find these samples.
Figure 2 shows the output of a simple data table, which is taken from the PrimeFaces DataList demo.
Listing 3 presents the markup for this dataList display. If you scroll to the bottom of the PrimeFaces showcase, you can see the markup in the dataList.xhtml tab.
In Listing 3, notice the value property of the dataList component. You can see that this references a dataListView object, and accesses the .cars1 property on it. The component is going to use the model object returned by that field. JSF tokens use conventional accessors to reference object properties, so .cars1 will refer to the getCars() getter on the object.
Next, notice the var="car" property. This tells the dataList component what variable to use when it iterates over the list of cars returned by the value field. These properties are specific to the dataList component, but the value property is very common. The var attribute is also conventional for components that iterate over lists.
In the body of the component in Listing 3, you can see the car variable is accessed via JSF expressions like #{car.brand}. Each iteration of the dataListView.cars1 instance will output the car.brand field.
Notice that the
You can see how the Facelets XML will drive this output by combining the data with the markup. Now let's look at the Java code behind it.
Listing 4 shows DataListView, the Java class that is used by the markup in Listing 3. You'll see shortly how the dataListView instance is associated with the DataListView class.
Listing 4 has a few other important elements, which we'll consider piece by piece.
First, notice that the DataListView class is annotated with @Named, which you can see from the import import javax.inject.Named; is part of JSF. The @Named annotation tells JSF this bean is part of the app. The @ViewScoped annotation informs JSF that the bean will live for just the life of the view.
JavaServer Faces (JSF) is a new standard Java framework for building Web applications. It simplifies development by providing a component-centric approach to developing Java Web user interfaces. JavaServer Faces also appeals to a diverse audience of Java/Web developers. "Corporate developers" and Web designers will find that JSF development can be as simple as dragging and dropping user interface (UI) components onto a page, while "systems developers" will find that the rich and robust JSF API offers them unsurpassed power and programming flexibility. JSF also ensures that applications are well designed with greater maintainability by integrating the well established Model-View-Controller (MVC) design pattern into it's architecture. Finally, since JSF is a Java standard developed through Java Community Process (JCP), development tools vendors are fully empowered to provide easy to use, visual, and productive develop environments for JavaServer Faces.
JavaServer Faces' Implementation of MVC
One of the key advantages of JSF is that it is both a Java Web user-interface standard as well as a framework that firmly follows the Model-View-Controller(MVC) design pattern. This makes JSF applications much more manageable because the user-interface code ( View) is cleanly separated from the application data and logic ( Model). To prepare the JSF context, which provides application data access to the pages, and to guard against unauthorized or improper access of the pages, all user interactions with the application are handled by a front-end "Faces" servlet ( Controller).
Figure 1: JavaServer Faces Implementation of MVC
The JSF Lifecycle
The Faces Controller servlet serves as the link between the user and the JSF application. It operates within the confines of a well defined JSF Lifecycle which dictates the entire flow of events between user requests. For example, upon an initial Web request to access a JSF application, the Faces controller servlet handles the request by first preparing the JSF context, which is a Java object that holds all application data. The controller then routes the user to the requested page. The page usually renders application data from the JSF context using a simple Expression Language. Upon subsequent requests, the controller updates any Model data, providing any new input has been entered. JSF developers have programmatic access to the entire JSF lifecycle at any time during its execution thus affording a high degree of control over the application's behavior at all times.
JavaServer Faces' User-Interface Components
The true power of JavaServer Faces lies in its user-interface component model where applications are merely built from collections of components that can render themselves in diverse ways for multiple client types. Vaguely similar to other proprietary technologies such ASP.Net, JSF's UI Component model technology offers unprecendented productivity by allowing the developer to construct Web user interfaces using pre-built user-interface (UI) Components as opposed to having to construct the user interface entirely from scratch. JSF UI Components come in many forms and can be as simple as an outputLabel which simply displays text or as complex as a dataTable which can represent a tabular data from collections of data such as from a database table.
The JavaServer Faces specification provides a set of base UI Components in its Reference Implementation which are very useful on their own. These include two libraries of components such as the "HTML" component library which largely mirrors the standard HTML input elements along with a "Core" library which aids in common application development tasks such as internationalization, and validating/converting input data. In addition to providing a base library of UI Components, the JSF API offers the ability to extend and create custom JSF UI Components providing additional functionality above and beyond the base components.
Additional User-Interface Component Libraries
Because of the richness and flexibility of the JSF API, many Java developers are beginning to create new JSF Component libraries and implementations. Oracle's ADF Faces is a fully compliant JSF component library which offers a broad set of enhanced UI Components for JSF application development. These include multiple renderers per client type, advanced tables, color and date pickers along with a host of general components such as menus, command buttons, shuttle choosers and progress meters.
Figure 2: Oracle's ADF Faces JSF UI Components
In addition to Oracle's ADF Faces there are other new JSF Component Libraries beginning to appear from both the Open Source and software vendor communities. MyFaces is an example of a new JSF UI Component Library being offered as an Open Source project through Apache. Myfaces also serves as an enhancement to the JSF base UI components in that they also have more extensive UI capabilities such as integrated Tiles support, Javascript enabled menus and Tree controls.
Figure 3: The Open Source MyFaces Implementation and UI Component Library
JSF UI Components' Pluggable Rendering Technology
One of the most compelling aspects of JSF's UI Component technology is it's pluggable rendering capability. JSF UI Components have the ability to render themselves differently depending on the client type viewing the component. For example a HTML browser will view an "HTML Browser Friendly" version of a particular UI Component whereas a Wireless or WAP enabled micro-device would view a "WML friendly" version of the same UI component! JSF makes this possible by de-coupling the UI Component from its rendering logic making it possible to create multiple renderers for the same UI Component. Different renders can be associated with the UI Component and at runtime the UI component can decide which renderer to use based on the requesting client type.
Figure 5: A Single ADF Faces Table Component Rendering Differently for Wireless and HTML Clients
It should also be pointed out that because of JSF's pluggable rendering capability it is possible for JSF UI Components to render any kind of data be it markup, such as HTML, XML, WML etc.., or binary data. For example UI Components can also render binary data such as an image streams or different document types such as SVG, PDF and Word.
A New Community of JSF Component Developers
As the community of JSF developers and enthusiasts continues to grow, there are now several Websites dedicated to further empowering independent JSF development.. JSFCentral is an example of a new Website solely dedicated to the JSF development community. It contains JSF technical information, product/component information as well as a vast listing of numerous JSF related articles.
(JSFCentral is located at: http://jsfcentral.com)
JSF Development Tools
Because JavaServer Faces is a standard Java technology, software development tools are fully empowered to offer advanced integrated development tools support for JavaServer Faces. This greatly enhances JSF's ease of use and power in that multiple vendors are now supporting JSF development to varying degrees. Oracle, Sun , Borland and IBM each offer development environments for JavaServer Faces. Since development tools vendors are competing at providing better, easier and more development environments, the future of IDE based JSF development looks great!
Figure 6: Oracle's JDeveloper Offers a Productive, Visual JSF Development Experience
The Differences –
Objective – There are fundamental differences in the objectives served by the technologies. JSP is primarily developed for creating dynamic web pages for small applications. It is very difficult to use it for large-scale applications as they are developed with a certain framework and component-based system. That is where JSF comes into the scene and it is a component-based system which is highly useful for large-scale projects. JSF uses MVC framework and hence, even the user interfaces and its components are reusable in a particular web page. While JSP is quite older and hence, fully developed, JSF is still in the developing stage and with every new version, major features are being added. For example, the latest version has added features like search expressions, push communications, extensionless URLs and likewise.
Architecture – JSF is a proper framework and that is why it is widely used in the web development industry. In technical terms is a component driven UI model system. It uses XML for view templates. FacesServlets is responsible for processing requests and sending required view templates, creating component trees, processing events and rending response to the clients. The state of the components is saved which is retrieved before creating another view. On the other hand, JSP is a request-driven technology and it is translated into servlets during the runtime. Even though it is request-driven, instead of using it independently, it can be used with view component of any server-side MVC design. The model could be JavaBeans while the controller can be Java Servlet.
Features – JSF has various multiple core features that are not present in JSP. The features present in JSF makes it suitable for presentation-type applications whereas JSP is more suitable for service-related applications. Ajax is one of the most popular UI designing technologies in today’s world and only JSP is compatible with Ajax. As a matter of fact, it is its integration with Ajax that makes it more popular than JSP.
Why Is JSF Better Than JSP?
The main difference between JSP and JSF lies in the way they operate. It is important to understand the working and flow of the two for the same web application to understand the differences. In JSP, one component has minimal impact on the other component. Therefore, you can create new views without having to write the model. Therefore, the application can be more flexible. But when it comes to complication web applications, it is difficult to maintain the structure as it is the case with JSP while developing small-scale applications. There can be code duplication and the structure can become a mess and maintenance can be difficult. Since JSP is a core technology, you can have different developers for different components but you have to be careful when it comes to integration as it can get messed up. That is why big companies avoid JSP for large-scale applications and there could be a lot of bugs and errors after the integration.
On the other hand, JSF can be divided into six phases so f development. The integration of components is seamless as it is a component-based technology and designed for large-scale applications. You can create and restore views that are used for showing information to the clients. You can update values as per you requirements without major changes. You can process validations and data type conversions like never before. Similarly, you can invoke applications to fulfill any request and render responses.
Java Server Pages (JSP) is a server-side programming technology that allows the creation of a dynamic, platform-independent method for developing Web-based applications. Java Server Faces (JSF) is a Java-based web application framework proposed to simplify web-based user interfaces' development integration.
JSP have it's own life cycle jsp_init() jsp_service() jsp_destroy
After first request JSP convert to .java file. There is three type of tag we are using 1.)Scriptless
Here developer can declare all those things which developer want to take the data
2.)Expression tag
Here developer can use some print related data
3.)Declaration
Here developer can declare some method related data.
Servlet have it's own life cycle.
After first request container will read the data from web.xml file then after out welcome fill will be display. Now onward after performing action it will search the url and after this process it will search the particular servlet there it self. service operation will perform.
JSF have it's own ui and it's life cycle can perform in six way,
For ui here for table here we are using panel grid and there is different faces for this that is.