JavaServer Faces are another way to take advantage of the MVC model for development. They are an important resource for reusing the view within an MVC design. This article describes an overview to the JavaServer Faces technology as well as how it works, and how it compares with similar technologies.
With software becoming increasingly the driving force in business everyday, enterprise development continues to evolve creating more extensive ways to manage information. With requirements of reusability and maintainability, it is no wonder component based methodologies present themselves. J2EE has done a phenomenal job in creating architecture and API’s for component-based development; JavaServer Faces are no exception.
JavaServer Faces simplify the creation of reusable user interface components in Java web applications. In short, JavaServer Faces encapsulate the complex portions of the view in MVC design. Originally, a client would send an HTML request to a J2EE web application. The implemented container would manage the request and send it off to a servlet controller. The servlet would then use Java Beans as the model, process information, and redirect the information to an appropriate view (JSP and HTML).
Herein lies a particular difficulty. Servlets are reusable components. If a servlet is implemented doing a particular task well, this servlet can be ported to multiple web applications with very little difficulty. This is the nature of component based development saving money and most importantly, time. Views by definition are proprietary to a particular web application. A personal website’s JSPs aren’t implemented on multiple web applications, because they have personal website information on them. JavaServer Faces eradicate this problem while providing even more pre-built functionality to the view portion of the MVC architecture. With JavaServer Faces, portions of a view on personal and business websites can be reused in numerous differing web applications. Moreover, they don’t even require the use of an HTML browser to display, and can be implemented to be rendered many different ways including WML. With this information in mind, how does it work?
Just like standard J2EE web applications, JavaServer Faces are powered by XML. Unlike standard J2EE web applications, this is not the application descriptor. JavaServer Faces implement another XML document alongside the application descriptor called the JSF configuration file. This configuration file declares the JavaServer Faces specific components such as: managed beans, validators, converters, navigation rules, and so forth. Although the syntax is beyond the scope of this application, this configuration file makes organization of the project incredibly easy as well as solidifies the loose coupling.
Besides linking XML, JavaServer Faces consist of two primary components. These components are JSF API and the tag libraries wiring JSF components to user interfaces. The JSF API is comprised of a series of specifications relating to: interface components, managed beans, validation, conversion, events, navigation, and rendering. The tag libraries contain the specification for integration of created components within a JSP page.
JSF user interface components represent component information and behavior. This component might be a button for example. This button would have attributes relating to the text displayed on the button, and when the button is clicked, it would fire an event. Of course, there is a framework provided to create custom user interface components. Another great features is the display for a particular component is independent of the component and a renderer is used to generate the display independent of a particular component.
Managed beans are java beans typically implemented to handle input and actions. EL can be used to bind a user interface component to a particular bean action or information. If the button example is used, the actionListener attribute of a button is set to a managed bean using EL. When the button is clicked, the method in the managed bean is fired. This method invocation is similar to swing and covers a lot of the event driven portion of JavaServer Faces. The user information is processed by the server, but what about validation?
Since validation is a must in any web application, integrated and custom validation is already provided in the framework. Simple validation rules can be applied to user input controls for things pertaining to lengths and ranges. The Common Validation API is also applied to almost all of the controls within JavaServer Faces. Since the validator framework is pluggable, it is easy to implement validation with any custom control as well. Now Java must handle the view redirection after the data is verified.
Navigation is one of the most interesting and powerful pieces of this package. Normally, the problem of navigation is generally solved through HTML links and server side redirection. Although this is sufficient, it creates a tight coupling between servlets, controls, and the display views. The navigation system within JavaServer Faces is managed through the JavaServer Faces configuration file. For any individual request pages, there can be a number of possible responses. These can all be managed with arbitrary labels which redirect to specified pages. For example: If I am specifying an authentication page, there can be a number of responses like success or failure or invalid username. These responses can all be individually mapped to independent pages. This gives an incredible amount of loose coupling keeping the component away from the individual implementation pages.
The other primary component of JavaServer Faces is the tag libraries. J2EE provides two different libraries. The JavaServer Faces core tag library and the JavaServer Faces HTML tag library. The core tag library accommodates the implementation of user interface elements in a form. This is validation, conversion, and event listeners. The HTML tag libraries house components for HTML aware browsers. These include input and output tags, command tags, and selection tags.
Although the setup of JavaServer Faces is similar to other technologies, JavaServer Faces have fundamental differences with similar implementations. Microsoft’s ASP.NET has a component based control implementation where the display code fires events to a code-behind file. The difference between Microsoft’s ASP.NET implementation and the JavaServer Faces implementation is the coupling. Since a code-behind is usually treated as one entity with the display, the ASP.NET implementation is simpler to use, but more tightly coupled with the view. JavaServer Faces are obviously useful, but what does it take to implement them?
To implement JavaServer Faces, one must first start with a JavaServer Faces compliant container. Once this is installed and configured, the only other pre-requisite is the latest Java Development Kit. Since this article is a primer to the technology and not a tutorial on creating JavaServer Faces, the actual code is beyond the scope of this article.
Although this article only scratches the surface of this incredible technology, it is easy to see JavaServer Faces are a phenomenal way to reuse MVC view code. They are pre-packaged with powerful tools, and are another way for developers to save time and effort within their development shops. For more information on implementing this technology, consult the sun website as they have an immense archive of tutorials.
Bibliography
JavaServer Faces Technology. The J2EE 1.4 Tutorial. Retrieved June 10, 2007 from
http://java.sun.com/j2ee/1.4/docs/tutorial/doc/JSFIntro.html
JavaServer Faces. Wikipedia.com. Retrieved June 10, 2007 from
http://en.wikipedia.org/wiki/JavaServer_Faces
Manganellore, Rakesh (2007) Introduction to JavaServer Faces. JavaBeat. Retrieved June 10, 2007 from
http://jsf.javabeat.net/articles/2007/05/java-server-faces-introduction/
Note: This article assumes you have done some Java web development in the past, and you are capable of compiling and executing web applications with J2EE.
Overview
J2EE has done some amazing things in progressing the creation of custom tags. Now it is fairly easy to integrate any custom HTML tag within your application further separating the view from designers. This article will show you how to implement a custom HTML tag that calculates the square of a number by simply placing <math:square num="12" /> into your web application. Hopefully, you can feel the power with this simple feature.
Creating the class
Every custom tag extends SimpleTagSupport. This is a class implemented by the J2EE spec which allows a class to output information to a jsp. So, lets get right to coding. Create a class in your web application that extends javax.servlet.jsp.tagext.SimpleTagSupport. If you are compiling by hand, the class file must go in the package structure under /WEB-INF/classes/ i.e. /WEB-INF/classes/com/cyberkruz/test/NewMath.class
l
Every attribute in your custom tag must have a Java Bean mutator property to go with it. This is handled with reflection to send the parameter to your class.package com.cyberkruz.test;
import java.io.*;
import javax.servlet.jsp.*;
import javax.servlet.jsp.tagext.SimpleTagSupport;
public class NewMath extends SimpleTagSupport {
private Integer num;
/**
* Method overridden which is called
* by the jsp.
*/
public void doTag() throws JspException, IOException {
// Gets the jsp context and prints the
// number squared.
this.getJspContext().getOut().print(this.num * this.num);
}
/**
* Sets a number that our custom
* tag squares.
* @param num The number to which
* we want to square.
*/
public void setNum(Integer num) {
this.num = num;
}
}
Configuring the application to use the class
Now, all we have to do is let our application know that the new tag is there. To do so, we can set up a TLD file which looks much like the document descriptor for configuring servlets. So lets do it! Create a new file called MyTags.tld and place it in the /WEB-INF directory. Then type the following:
<?xml version="1.0" encoding="iso-8859-1" ?>
<taglib xmlns="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi="http://www.w3c.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee/web-jsptaglibrary_2_0.xsd"
version="2.0">
<tlib-version>1.2</tlib-version>
<uri>myTags</uri>
<tag>
<description>Custom tags</description>
<name>Square</name>
<tag-class>com.cyberkruz.test.NewMath</tag-class>
<body-content>scriptless</body-content>
<attribute>
<name>num</name>
<required>true</required>
<rtexprvalue>true</rtexprvalue>
</attribute>
</tag>
</taglib>
This file configures our web application to use our new custom tag. Multiple tags can be placed and mapped with this single file. The taglib directive just specifies the schemas for this particular file and version. The uri specifies what location these tags are being mapped to. Under the tag element, the description and name should be pretty straight forward. The tag-class element points this tag to the class that we wrote previously. the body-content is stating that we don't want inline scripting for this element. Now the attribute tag is fairly interesting. While optional, it maps the num variable to our setter in the class we specified. Then, it says we must have it there (required element) and it can be specified at run time (rtexprvalue).
Now all we have to do is use it!
Place our new tag in a jsp
Allowing our jsp to use the custom tag is the easiest part. It only requires a single declaration.
<%@ taglib prefix="math" uri="myTags" %>
The taglib keyword tells the jsp what we are trying to do. The prefix is what we want to put before the tags when we call them, and the uri points to the uri specified in the tld file. This is going to load every tag that is configured in that tld file that we made previously.
Now, let's put it in a jsp. Create a jsp file called SimpleTest.jsp and place it in your web application. Place the following in your jsp:
<%@page language="java"
contentType="text/html; charset=ISO-8859-1"
pageEncoding="ISO-8859-1"%>
<%@ taglib="" prefix="math" uri="myTags" %>
<html>
<head>
<title>SimpleTest</title>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
</head>
<body>
10 squared is: <math:Square num="10" />.
</body>
</html>
Run it on your web server and... YAY! This is a base introduction to what you can do with custom simple tags. More information about how to use these is below. Enjoy!
More information
http://java.sun.com/j2ee/1.4/docs/tutorial/doc/JSPTags7.html
Thomas Holloway and I developed a powertoy for building, validating, and parsing regular expressions. Thomas posted a wonderful article with more information here. This application is definitely a handy one. We have feedback from many University students and professors about the use of the software. Also, we have questions about how the Swing interface was implemented. Overall, a wonderful product that will hopefully be very handy to developers. Feel free to build from the subversion, but be warned, the project is not released yet.
Release
We planned on having a release for the software last week. However, like most software, stuff happened. I will be posting the beta as soon as I get back to Utah (another week or two).
Differences Between Java 5 and 6
Abstract
This article contains information about the differences between the Java 5 and Java 6 frameworks. More specifically, it highlights the new features added with the latest release of Java 6. The article covers security, gui, speed, and problems found with the current release. It discusses opinion on the subject as well as attempting to provide fact about the latest Java technology. As our projects gear towards Windows applications, so does this article.
With the new Java 6 emerging, developers all over the world cringe with the questions of compatibility and upgrade. Others are optimistic about chance to tinker with new API's and tool sets. Although there are a decent number of changes in this update, this article is aimed to expose only the ones we found interesting or important. If we miss some, there is a full list of changes linked at the end of the document. Java 6 appears to be a bunch of small updates packaged as a new release. This is a good thing for those worried about the scope of an upgrade. For those interested in tinkering with new features, the scripting engines and graphical add-ons should suffice. Although there aren't near as many updates as compared to the Java 4 to 5 upgrade, there are definitely some interesting new additions to the new framework.
First, lets talk optimization. With an expansion of any API or system, slowing down is always a primary concern. However, a large portion of the new Java enhancements are actually speed related. How Java handles desktop applications is now more optimized with faster loading times and double buffering. The adaptive optimization system does even more things to optimize your code upon compilation and runtime. This also applies to split byte code verification which is now done partially at compile-time and partially at runtime. As a note, byte code verification was originally done right when it was about to be used, which slows things down. With all these speed increased, did they mention security features?
This security section starts with an interesting little tidbit about Web Start Applications. Sun appears to be heavily pushing Java 6 with what they call “Security Versioning.” It states that Java Web Start applications not identifying themselves with the latest version of Java will require users to explicitly give permission before executing a particular Java Web Start program. This seems mildly annoying but apt in moving development to newer versions. The site says that signed Java Web Start applications are not affected by the change. Another main security feature added is GSS/Kerberos integration and a certificate request framework apparently working under a large number of protocols. Java added support for a numerous amount of new encryption types. Some little features include SSLParameters class that encapsulates the configuration of SSL connections and new parameters and options for some of the security related classes. The changes even filter down to the socket level. Socket read timeouts are now fully supported where as before, there were inconsistencies. So if you are treading into socketland, you will be happy to know that the libraries are still being supported very well. Networking updates don't end at the low level however.
Web Services have a wonderful set of updates as well. Cryptography directly on XML is an awaited feature on the enterprise side of development that made it into this release. Support for .NET web services is another interesting feature added to the new implementation allowing ease of interoperability when designing large systems. This feature is documented, although we have not tested it ourselves. The XML libraries use STAX for message processing, and have 2 new tools to aid in development and deployment. They also included a few new classes to make connections and publishing more simple then ever before.
Developers Developers? Yes indeed. From the text above, you can see that Java 6 caters to the developer (as they should since they are writing a development language). And it doesn't stop there. A developer can now compile code directly from other code within a Java application. What about if the code breaks? All the debugging information including warnings, errors, etc... get sent back to the application so the application can handle things properly. Code generation now seems more powerful then ever. There are also a few more neat little tricks like developers attaching to an existing JVM for more in-depth debugging. Don't laugh .NET developers, we know you can do that already.
Away from the enterprise server side of things, the User Interface updates are definitely of note. For a Windows developer, these updates have not come fast enough. True double buffering is one notable feature which buffers every window instead of every application. Another nice feature is baseline/gap API's and text-component printing. They even are nice enough to throw in a custom splash screen that can be used with a swing application for those lengthy load times. Sun seems to finally understand that desktop GUI's look different depending on the operating system. They have designed the latest version of swing to look different based on the graphical engine running the swing code. Before, this required special code during the Jframe instantiation. For native look and feel, the features include: GTK Native Look and Feel, Avalon Look and Feel, as well as a number of Windows based fixes. These updates are rumored to speed up the graphical side of things quite a bit as previously stated. To add a few more flavors of icing on the cake Java applications have the ability to access desktop applications, they have live updating on window resizing (finally), and some miscellaneous hardware acceleration tweaks are involved. All in all, I would say Java now has a pretty powerful forms application development library. What more could you ask for?
As for miscellaneous features, Java has implemented a nice way to integrate scripting languages in with Java source code. The actual Sun site directly comments on merging JavaScript, Ruby, and Python into custom scripting engines which allow different team members with different backgrounds to integrate code. This framework allows scripting languages to access internal parts of your application with a small code base as the scripting engine. We didn't spend an extensive amount of time delving into this feature although it is something worth exploring in the future.
With all of these cool new API upgrades, there are some things that confuse us. For example, some of the speed specification documentation is missing from the Sun website. The whitepaper for Java 6 performance redirects to a page simply saying “Coming Soon.” Also, they have appeared to add some features that the community was directly against even though this release was set on community action and involvement. A small scale HTTP server was added to Java 6 which is based on a bug report sent by someone in the community. Every person commenting on the particular bug deemed it unnecessary. As well, a few data types were added to the framework that appeared to be fairly meaningless. The double sided queue was one of those data types. One man's bloat is another man's godsend though; I hope people find use in the new types. The most immense bother is the one to one relationship still required by the JVM to launch desktop applications. We are hoping this problem will be dealt with in the near future. The need for a separate JVM for interpreted language was fixed with .NET, and users don't enjoy the lengthy load times associated with launching two applications for every one application. We won't mention the memory waste.
Despite the issues, every developer knows that ironing out problems takes a lengthy amount of time. This especially applies to replacing production code which many developers currently rely on. With that said, don't expect things to be perfect any time soon. The emergence of Java 6 brought some new possibilities in development to the table which everyone loves, although we didn't see many things catering to our love of coding to robots. There are only a few complaints about the new framework, and none of them seem to hinder the framework enough to justify not upgrading (this especially applies to those interested in Web services and those affected by “Security Versioning”. These new features are essential as this language makes an effort to stay on top.
References
Java SE 6 Release Notes http://java.sun.com/javase/6/webnotes/features.html
Bruno, Eric (2006, February 27) Java SE First Impressions: A Desktop Winner
http://www.devx.com/Java/Article/30722
Java 6 Security Enhancements
http://java.sun.com/javase/6/docs/technotes/guides/security/enhancements.html
Mullan, Sean (2006, February 15) Mustang Beta is out! Here's what's new in security.
http://weblogs.java.net/blog/mullan/archive/2006/02/mustang_beta_is_1.html
vivekp (2006, December 12) Webservices in JDK 6
http://weblogs.java.net/blog/vivekp/archive/2006/12/webservices_in.html
]]>