AJAX and Mozilla XUL with JavaServer Faces
Continuing Our Exclusive JDJ Series on JSF – This Month, Introducing a New Open Source Project
May. 12, 2007 05:45 PM
In our previous JDJ article - Rich Internet Components with JavaServer Faces - we discussed how JavaServer Faces can fulfill new presentation requirements without sacrificing application developer productivity building Rich Internet Applications (RIA). We discussed how JSF component writers can utilize technologies, such as AJAX and Mozilla XUL, to provide application developers with rich, interactive and reusable components.
In order to use AJAX and Mozilla XUL with JSF, component writers have to make sure to provide any resource files need by these technologies, such as images, style sheets, or scripts. The standard approach to providing resource files for a JSF component library is to serve them directly out of the web application root file system. These resources are usually packaged in an archive (such as a ZIP file), and shipped separately from the JSF component library.
This article introduces a new open source project - Weblets - which can be found on the java.net website (http://weblets.dev.java.net). The goal of this open source project is to provide JSF component writers with a facility that can serve resource files out of a Java archive (JAR), rather than serving them from the web application root file system. Unlike traditional web applications, which have statically configured URL mappings defined in web.xml, there is a need for dynamic configuration of URL mappings, based on the presence of a component library JAR. In essence, Weblets provide developers with an easy way to package web application resources in the same Java archive (JAR) that their implementation code resides in.
It is important to note that the JavaServer Faces HTML basic RenderKit does not have any images, styles or scripts, so there is no standard solution to the Faces resource packaging problem.
Code sample 1. The encodeBegin() method in the sample Renderer.
ViewHandler handler = context.getApplication().getViewHandler();
Although the installables approach is convenient for the JSF component author, it does increase the installation burden on the application developer, who must remember to extract the installables archive each time the component library is upgraded to a new version. Therefore, we need a way to package our additional resources into the same JAR file containing the Renderer classes, simplifying deployment for application developers using our component library.
A weblet acts as a mediator that intercepts requests from the client and uses short web URLs to serves resources from a JAR file. Unlike the Servlet or Filter approach, a Weblet can be registered and configured inside a JAR, so the component library Renderers, their resource files, and the Weblet configuration file (weblets-config.xml) can all be packaged together in the same JAR. The Weblet Container can be registered just once in the web application configuration file - web.xml - for all component libraries. There is no need to separately deploy additional installables when the component libraries are upgraded to new versions.
It is important to note that all resources served up by Weblets are internal resources, used only by the Renderer. Any resources, like images, which are provided by the application, are supplied as component attribute values, and loaded from the context root as external resources.
After receiving the rendered markup for the main page, the browser downloads each additional resource using a separate request. Each request for a weblet-managed resource is intercepted by the WebletsPhaseListener, which then asks the WebletContainer to stream the weblet-managed resource file out of the component library JAR.
The WebletContainer is designed to leverage the browser cache where possible. This improves overall rendering performance by minimizing the total number of requests made for weblet-managed resource files.
To ensure flexibility, optimization, and avoid collisions with existing web application resources, Weblets can be configured by application developers to override any default settings provided by the component author.
Using Weblets in a Component library
Our component library packages resources in the org.myapp.faces.renderer.html.resources Java package and makes them available to the browser using the default URL mapping of /myresources/*.
Code Sample 2. Weblets configuration file, weblets-config.xml.
The PackagedWeblet is a built-in Weblet implementation that can read from a particular Java package using the ClassLoader and stream the result back to the browser. The package initialization parameter tells the PackagedWeblet which Java package to use as a root when resolving weblet-managed resource requests.
Reader Feedback: Page 1 of 1
Latest Cloud Developer Stories
Subscribe to the World's Most Powerful Newsletters
Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
SYS-CON Featured Whitepapers
Most Read This Week