Creating a wide range of Internet components based on AJAX and JSF (1)

In the previous article, we discussed how to use JSF to meet the needs of the next-generation descriptive layer development without sacrificing the efficiency of Web developers in building RIA. We have discussed how JSF component creators can use AJAX and Mozilla XUL technologies to provide Web developers with rich interactive and reusable components.

To jointly use AJAX and Mozilla XUL technologies in JSF development, component creators must provide any resource file examples, style tables, or scripts required by these technologies ). The standard way to provide resource files for a JSF component library is to provide services directly from the Web application root file system. These resources are usually packaged with an archive file, such as a ZIP file, and released independently of the JSF component library.

This article introduces a new open source project Webletshttp: // weblets.dev.java.net ). The goal of this project is to provide a tool for JSF component developers so that developers can extract resource files directly from JAR, rather than providing services from the Web application root file system. Unlike traditional web applications that use URL ing that defines static configuration in the Web. xml file, they need a URL ing THAT is dynamically configured based on the existing component library JAR file. In essence, Weblets provides developers with an easy way to package Web applications-the Web application implementation code can reside in the same Java JAR file with its resource files.

I. Resource Loading

Let's assume that we have a JSF component that requires a JavaScript file myScript. js to serve the client. This JavaScript file is used by components to realize rich interaction with users to some extent. Traditionally, this JavaScript file is determined by the relative path in the actual builder code of the Web application service, which is hardcoded to the jsf component. In this way, Web developers need to release other related resources that are delivered and packaged in the form of independent document files.

It is worth noting that the jsf html basic RenderKit does not have any images, patterns, or scripts. Therefore, there is no standard solution to the Faces resource Packaging Problem.

The following sample generator code shows an installable method that provides a JavaScript file/myresources/myScript. js service from the root file system of the Web application.

ViewHandler handler = context.getApplication().getViewHandler(); String resourceURL = handler.getResourceURL(context，"/myresources/myScript.js"); out.startElement("script"， null); out.writeAttribute("type"， "text/javascript"， null); out.writeAttribute("src"， resourceURL， null); out.endElement("script");

Although this installable method facilitates the author of The JSF component, it does increase the installation burden for Web developers-they must remember: every time you upgrade the component library to a new version, you must extract the installable documents. Therefore, we need a new method to package other resources of our program into the same JAR file containing the Renderer class, in order to simplify the issue of Web developers using our component library for publishing.

Ii. Use Weblets

The main idea of this open-source Weblets project is to solve the resource Packaging Problem in a general and scalable way so that it can be used by all JSF component creators, at the same time, the minimum installation task is handed over to Web developers.

In fact, a Weblet acts as a "reschedule"-it interprets requests from the client and uses a short Web URL to provide resource services from a JAR file. Unlike Servlet or Filter, a Weblet can be registered and configured inside a JAR, so that the component library builder, their resource files, and the Weblet configuration file weblets-config.xml) can be packaged into the same JAR file. For all component libraries, the Weblet container can only be registered once in the Web application configuration file web. xml. When you upgrade the component library to a new version, you do not need to independently release other installable programs.

It is worth noting that all resources served by Weblets are internal resources and can only be used by generators. All resource examples provided by applications are provided in the form of component property values and loaded from the root context as external resources.

Iii. Weblet Architecture Analysis

Although Weblets is designed to be used by any Web Client, Weblets implementation has been integrated with JSF by using a custom ViewHandler and WebletsViewHandler. See figure 1. During the generation of the main JSF page, WebletsViewHandler is responsible for converting the URL of a specific Weblet resource to the actual URL used by the browser to request resources hosted by the Weblet.

Figure 1. Advanced view of Weblet Architecture

After receiving the annotation generated for the master page, the browser uses an independent request to download other resources. In this case, each request downloads a Weblet-managed resource) and is intercepted by WebletsPhaseListener, webletContainer must "stream" The Weblet-hosted resource files and export them from the JAR library.

WebletContainer is designed to make full use of browser cache. In this way, the overall data generation performance can be greatly improved by minimizing the number of requests for Weblet-managed resource files.

To ensure flexibility and optimization, and avoid conflicts with existing Web application resources, Web developers can configure Weblets to overwrite any default settings provided by component authors.

4. Apply Weblets to the component library

Weblets is configured with a weblets-config.xml file that must be stored in the/META-INF directory of the component library JAR. Configuring a Weblet is similar to configuring a Servlet or a Filter ). Each Weblet entry in the weblets-config.xml file has a Weblet name, implementation class, and initialization parameters as shown in List 1 ). Weblet associates a special URL model with a specific webletname example such as org.myapp.html. The Weblet name and default URL pattern define the public API of the resources managed by the Weblet. Note that the names and URL modes should not be modified between different release versions of your component library for backward compatibility.

List 1: Weblets configuration file weblets-config.xml

org.myapp.html net.java.dev.weblets.packaged.PackagedWeblet package org.myapp.faces.renderer.html.resources org.myapp.html /myresources/*