The World's Favorite Open Source GPL J2EE CFML Runtime Engine

BlueDragon Developer's Journal

Subscribe to BlueDragon Developer's Journal: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get BlueDragon Developer's Journal: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Open BlueDragon Authors: Reuven Cohen, Elizabeth White, Michael Sheehan, John Gauntt, Salvatore Genovese

Related Topics: RIA Developer's Journal, Kaazing Journal

RIA & Ajax: Article

Creating AJAX and Rich Internet Components with JSF

Introducing a new open source project

When serving packaged resources from a JAR, extra care must be taken not to make Java class files or other sensitive information accessible by URL. In desktop Java applications, resource files are often stored in a sub-package called "resources" underneath the Java implementation classes that use the resource files. The same strategy is also appropriate for packaged resources in JavaServer Faces component libraries, and has the security benefit of ensuring that only the resource files are accessible by URL. All other contents of the JAR file, including Java implementation classes, are not URL accessible because no Java classes exist in either the "resources" package or in any sub-package of "resources."

Weblets Protocol
Having covered how to configure Weblets, it's time to look at how we can reference resources defined by the Weblet in our renderer. The syntax, defined by the Weblet contract, for returning a proper URL to the JSF page is as follows:

<prefix><weblet name><resource>

The prefix indicates that this is a Weblet-managed resource, and this is followed by the Weblet name and the resource requested.

Previously, in our Renderer class, we passed the URL /myresources/myScript.js as an argument to the ViewHandler's getResourceURL() method. In the code sample below, we amend this to use the Weblet protocol instead.

ViewHandler handler = context.getApplication().getViewHandler();
String resourceURL = handler.getResourceURL(context, "weblet://org.myapp.html/myScript.js");
out.startElement("script", null);
out.writeAttribute("type", "text/javascript", null);
out.writeAttribute("src", resourceURL, null);

The Weblet protocol-like syntax is convenient and easy to understand. The syntax starts with weblet://, followed by the Weblet name, e.g., org.myapp.html, and finally the path info or resource file, e.g., /myScript.js. Notice that neither the URL mapping nor the version number are included in the Weblet resource syntax. The Weblet URL mapping and version number are used by the WebletsViewHandler to create a resource URL that the Weblet will service.

When the component writer is not using Weblets, he would not be using the weblet:// resource path syntax and would distribute a separate installables zip. When the component writer moves to Weblets, he would start using weblet:// resource path syntax in the Renderer, and include the resources in the JAR. There is no benefit to using a mixture of these approaches for resources in the same version of the same component library.

Using Weblets in a JSF Application
In order to simplify setup for the application developer, component writers should select a default URL mapping for their component libraries. There is no need for the application developer to add any Weblet-specific configuration to the web.xml file, since the WebletsPhaseListener will be invoked automatically to service incoming requests for Weblet-managed resources.

As a new open source project, Weblets has tremendous possibilities to provide a defacto generic and configurable resource loading facility for Web clients and the JSF component community. The key differentiators are simplified packaging of JSF components and their resources, and a minimized overhead of installing and setting up JSF component libraries for a particular Web application project.

This article has explored a new way of packaging resources with JSF components. You should now be able to leverage Weblets in your own component library by including a suitable weblets-config.xml file and using the weblet:// protocol-style syntax to reference Weblet-managed resources.

In our next article in this series of building "Rich Internet Components with JavaServer Faces," we are going to look at how we can design JSF components using AJAX and Weblets.

More Stories By Kaazing Blog

Kaazing is helping define the future of the event-driven enterprise by accelerating the Web for the Internet of Things.

More Stories By John Fallows

John brings to Kaazing his 17 years’ experience in technology development and software design, and is considered a pioneer in the field of rich and highly interactive user interfaces. As CTO he formulates Kaazing Corporation’s vision of enabling mobile users, marketplaces and machines to connect and communicate in real-time, more reliably and at unprecedented scale. He defines the architecture of the Kaazing product suite and oversees its development. Prior to co-founding Kaazing, John served as Architect for Brane Corporation, a startup company based in Redwood City, California. Before joining Brane, he was a Consulting Member of Technical Staff for Server Technologies at Oracle Corporation. During his last five years at Oracle, he focused on designing, developing, and evolving Oracle ADF Faces to fully integrate Ajax technologies. Originally from Northern Ireland, he received his MA in Computer Science from Cambridge University in the United Kingdom and has written several articles for leading IT magazines such as Java Developer’s Journal, AjaxWorld Magazine, and JavaMagazine (DE), and is a popular speaker at international conferences. He is co-author of the bestselling book Pro JSF and Ajax: Building Rich Internet Components (Apress).

Comments (7)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.