JavaServer Faces Note(1)

JavaServer Faces Note(1)
JSF makes it easy to develop web applications by bringing support for rich, powerful user interface components (such as text boxes, list boxes, tabbed panes, and data grids) to the development world.

A child of the Java Community Process, JSF is destined to become a part of Java 2 Enterprise Edition(J2EE).

RAD means Rapid Application Development.
RAD tools typically had four layers:
1) An underlying component architecture
2) A set of standard widgets
3) An application infrasturcture
4) The tool itself

The underlying component architectures were extensible enough to spawn an industry of third-party component developers like Infragistics and Developer Express.

In terms of the four layers of a RAD tool, JavaServer Faces defines three of them: a component architecture, a standard set of UI widgets, and an application infrastructure.
JSF's component architecture defines a common way to build UI widgets. This architecture enables standard JSF UI widgets (buttons, hyperlinks, checkboxes, text fields, and so on), but also sets the stage for third-party components.

Components are event oriented, so JSF allows you to process client-generated events(for instance, changing the value of a text box or clicking on a button).

IBM'S WebSphere Application Developer (WSAD) has been expanded to support JSF applications in addition to the seemingly endless amount of other technologies it supports. You can visually build JSF applications, and mix-and-match other JSP tag libraries using WSAD's familiar Eclipse-based environment.

Oracle's JDeveloper will have full-fledged support for JSF, complete with an extensive array of UIX components, which will Integrate with standard JSF applications. It will also support using components with its Application Development Framework (ADF).

Sun's Java Studio Creator is an easy-to-use, visually based environment for building JavaServer Faces applications. You can easily switch between designing JSF pages visually, editing the JSP source, and writing associated Java code in an environment that should seem familiar to users of Visual Studio.NET, Visual Basic, or Delphi.

Just in case all of this sounds like magic, we should point out a key difference between JSF and desktop UI frameworks like Swing or the Standard Widget Toolkit (SWT): JSF runs on the server.
As such, a Faces application will run in a standard Java web container like Apache Tomcat [ASF, Tomcat], Oracle Application Server [Oracle, AS], or IBM WebSphere Application Server [IBM, WAS], and display HTML or some other markup to the client.

JSF 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, esponses, and markup.

JSF was introdced as Java Specification Request (JSR)127 by Sun in May 2001; The final version of the specification, JSF1.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.

JSF is a UI component framework that works with tools and runs inside J2EE containers, this makes good sense. 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). 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.

HTTP is a simple protocol and is a "stateless" protocol. 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.
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.
JSF was introduced so that developers can forget that they're using the protocol at all.

Java Servlet application programming interface is all about: providing an object-oriented view of the world that makes it easier to develop web applications. HTTP requests and responses are encapsulated as objects, and you get access to input and output streams so that you can read a user's response and write dynamic content. Requests are handled by servlets -- objects that handle a particular set of HTTP requests.
A standard J2EE web application is, by definition, based on the Servlet API. Servlets run inside a container, which is essentially a Java application tht performs all of the grunt work associated with running multiple servlets, associating the resources grouped together as a web application, and managing all sorts of other services.
The Servlet API also provides lots of other goodies, like security, logging, life-cycle events, filters, packaging and deployment, and so on. These features all form the base of JSF.
As a matter of fact, JSF is implemented as a servlet, and all JSF applications are standard J2EE web applications.

Most web applications serve dynamic content from a data store -- usually a database.
Since the early days of the Web, however, there has been a need for software that aggregates information from different data sources into an easy-to-use interface. These types of applications, called portals, were originally the domain of companies like Netscape and Yahoo. Each data source is normally displayed in a region within a web page that behaves similarly to a window -- you can close the region, customize its behavior, or interact with it independent of the rest of the page. Each one of these regions is called a portlet.
The Portlet specification defines the Portlet API, which, like the Servlet API, defines a lot of low-level details but doesn't simplify UI development or mask HTTP.
You can use ordinary JSF components, event handling, and other features inside portlets, just as you can inside servlets.

JavaServer Pages look like an HTML page, but they have special tags that do custom processing or display JavaBean values, and can also have Java code embedded in them. You can create your own custom tags to perform additional processing, and there's a useful set of standard tags called the JSP Standard Tag Library (JSTL).
Even though JSP is the industry standard display technology, you can choose among many alternatives. You could use a full Extensible Markup Language/Extensible Style Sheet Language Transformations (XML/XSLT) approach with something like Cocoon [ASF, Cocoon], or a stricter template-based approach like Velocity [ASF, Velocity] or WebMacro [WebMacro].
One of the key design goals of JSF was to avoid relying on a particular display technology. So JSF provides pluggable interfaces that allow developers to integrate it with various display technologies.
JSP and JSF are standard Java technology, so it's no surprise that Faces comes with a JSP implementation (via custom tags) right out of the box. And JSP is the only display technology that must be integrated with JavaServer Faces.

MVC: Model-View-Controller.
In software, the view is the presentation layer, which is responsible for interacting with the user. The model is the business logic and data, and the controller is the application code that responds to user events and integrates the model and view. This architecture ensures that the application is loosely coupled, which reduces dependencies between different layers.
Model2 is a variation of MVC that's specific to web application. The basic point is that:
1) The model can consist of plain old Java object(POJOs), EJBs, or something else.
2) The view can be JSPs or some other display technology.
3) The controller is always implemented as a servlet.
This separation allows for unit testing at each layer, and also lets different parties work with the layers independently.
These benefits are exactly why most frameworks, including JSF, support some variation of the MVC design pattern.

JSF, Struts, and other frameworks
Java web frameworks, like Struts [ASF, Struts] and WebWork [OpenSymphony, WebWork], help with form processing and other issues such as enforcing Model2, integrating with data sources, and controlling references to all of the application's resources centrally via XML configuration files. These foundation frameworks provide extensive underpinnings but don't mask the fundamental request/response nature of HTTP.
Other frameworks, like Tapestry [ASF, Tapestry], Oracles's Application Development Framework (ADF) UIX [Oracle, ADF UIX], and SOFIA [Salmon, SOFIA], provide a UI frameworks, which include JSF, is to simplify the entire programming model.

In essence, the context is the container for all of the components. A container is a system that hosts components and provides a set of services that allow those components to be manipulated.
The phrase "deployed independently" means that a component is a self-contained unit and can be installed into a container.
A UI component, or control, is a component that provides specific functionality for interacting with an end user. Classic examples include toolbars, buttons, panels, and calendars.
JSF sets the stage for things desktop developers take for granted: a wide selection of packaged UI functionality with extensive tools support. It also opens the door for creating custom components that handle tasks specific to a particular business domain -- like a report viewer or an interest calculator.

[@more@]

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/301743/viewspace-927300/，如需轉載，請註明出處，否則將追究法律責任。