| home / programming / java_server / 1 |    [previous][next] |
|
|
|
If you click a button in a Swing application, it will fire an event that you can handle directly in the code that resides on the desktop. In contrast, web browsers don’t know anything about JSF components or events; they just know how to
Figure 1.4 A high-level view of a JavaServer Faces application. JSF makes web development easy by providing support for UI components and handling a lot of common web development tasks.
display HTML.3 So when you click on a button in a Faces application, it causes a request to be sent from your web browser to the server. Faces is responsible for translating that request into an event that can be processed by your application logic on the server. It’s also responsible for making sure that every UI widget you’ve defined on the server is properly displayed to the browser.
Figure 1.4 shows a high-level view of a Faces application. You can see that the application runs on the server and can integrate with other subsystems, such as Enterprise JavaBeans (EJB) services or databases. However, JSF provides many additional services that can help you build powerful web applications with less effort. JavaServer Faces has a specific goal: to make web development faster and easier. It allows developers to think in terms of components, events, backing beans, and their interactions, instead of requests, responses, and markup. In other words, it masks a lot of the complexities of web development so that developers can focus on what they do best—build applications.
3 Technically, they do a lot of other things, like execute JavaScript or VBScript, display XML and XHTML, and so on.
NOTE JSF is a technology, and this book covers it as thoroughly as possible in several hundred pages. Tools sugarcoat a lot of pieces of the development puzzle with graphical user interface (GUI) designers that generate JSP, screens that edit configuration files, and so forth. Throughout this book, we’ll show you the real Java, JSP, and XML code and configuration that JSF uses, while giving you a sense of where the tools can make your life easier. With this approach, you’ll have a full understanding of what an IDE does behind the scenes, which is extremely useful for maintenance of your application after it’s built, and also for situations where you need to move from one IDE vendor to another. And, of course, if you don’t like IDEs at all, knowing how things actually work is essential. (If you are a big IDE fan, don’t worry—we show screen shots of different tools throughout the book, and online extension appendix B covers three of them in detail).
One of the best things about the Java Community Process (JCP), Sun Microsystems’s way of extending Java, is that a lot of great companies, organizations, and individuals are involved. Producing a spec through the JCP isn’t exactly speedy, but the work can be quite good. JavaServer Faces was introduced as Java Specification Request (JSR) 127 by Sun in May 2001; the final version of the specification, JSF 1.0, was released on March 3, 2004, and JSF 1.1 (a maintenance release) arrived on May 27th, 2004. The companies and organizations (other than Sun) involved in developing Faces include the Apache Software Foundation, BEA Systems, Borland Software, IBM, Oracle, Macromedia, and many others.
The products developed by these companies can be put into three categories (many fit in more than one): J2EE containers, development tools, and UI frameworks. Because JavaServer Faces is a UI component framework that works with tools and runs inside J2EE containers, this makes good sense. What’s significant is the fact that the group includes many industry heavyweights. This means that you can expect JSF to have a lot of industry support. And if your vendor doesn’t support JSF, you can download Sun’s reference implementation for free [Sun, JSF RI]. To keep up with the latest JSF news, articles, products and vendors, check out JSF Central [JSF Central], a community site run by the author.
All JSF applications are standard Java web applications. Java web applications speak the Hypertext Transfer Protocol (HTTP) via the Servlet API and typically use some sort of display technology, such as JavaServer Pages (JSP), as shown in figure 1.4. The display technology is used to define UIs that are composed of components that interact with Java code. Faces applications can also work inside of portlets, which are similar to servlets. JSF’s component architecture uses Java- Beans for exposing properties and event handling.
In this section, we briefly describe these technologies and explain how they relate to JSF. If you’re already familiar with Java web development basics and understand how they relate to JSF, you may want to skip this section.
Diplomats and heads of state come from many different cultures and speak many different languages. In order to communicate, they follow specific rules of ceremony and etiquette, called protocols. Following protocols helps to ensure that they can correspond effectively, even though they come from completely different backgrounds.
Computers use protocols to communicate as well. Following an established set of rules allows programs to communicate regardless of the specific software, hardware, or operating system.
The World Wide Web (WWW) started as a mechanism for sharing documents. These documents were represented via the Hypertext Markup Language (HTML) and allowed people viewing the documents to easily move between them by simply clicking on a link. To serve up documents and support this hyperlinking capability, the Hypertext Transfer Protocol (HTTP) was developed. It allowed any web browser to grab documents from a server in a standard way.
DEFINITION The Web was originally designed for static content such as academic documents, which do not change often. In contrast, dynamic content, such as stock information or product orders, changes often. Dynamic content is what applications usually generate.
HTTP is a simple protocol—it’s based on text headers. A client sends a request to a server, and the server sends a response back to the browser with the requested document attached. The server is dumb4—it doesn’t remember anything about the client if another document is requested. This lack of memory means that HTTP is a “stateless” protocol; it maintains no information about the client between requests.
The stateless nature of HTTP means that it’s able to scale well (it is, after all, the protocol of the Internet, and the Internet is a huge place). This property isn’t a problem for the static documents that HTTP was originally developed to serve. But imagine what it’d be like if a valet parked your car but didn’t give you a ticket and didn’t remember your face. When you came back, he’d have a hard time figuring out which car to retrieve. That’s what it’s like to develop an application in a stateless environment. To combat this problem, there are two possibilities: cookies and URL rewriting. They’re both roughly the same as the valet giving you a ticket and keeping one himself.
No matter what language you use, if you’re writing a web application, it will use HTTP. Servlets and JSP were developed to make it easier to build applications on top of the protocol. JavaServer Faces was introduced so that developers can forget that they’re using the protocol at all.
| home / programming / java_server / 1 | [previous][next] |
Legal Notices, Licensing, Reprints, Permissions, Privacy Policy.
Advertise | Newsletters | Shopping | E-mail Offers | Freelance Jobs 
Created: March 27, 2003
Revised: November 23, 2004
URL: http://webreference.com/programming/java_server/1
