 | |
The Java Studio Creator application development tool, Sun Microsystems' IDE for creating web applications, is now being updated in a new release (codenamed Reef Shark) that provides enhanced usability and a richer design-time experience for visual developers. The IDE is built on JavaServer Faces technology, whose origin goes back to Sun Microsystems' Senior Staff Engineer, Craig McClanahan. McClanahan developed the Apache Struts Framework as an open source developer in 1998 and found, to his surprise, that it became the standard web application architecture for the Java 2 Platform, Enterprise Edition (J2EE) space. The Struts Framework was consequently integrated into major application servers. By 2000, McClanahan was employed at Sun, as web application frameworks began to proliferate and the need for a standard became clear. JSR 127 was introduced in the Java Community Process (JCP) to solve the problem of creating base-level APIs for user interface components in web applications. JavaServer Faces 1.0 came into being in March 2004, with McClanahan serving as co-specification lead. With JavaServer Faces offering substantial improvements over Struts as an application framework, and the new release of Java Studio Creator providing a more productive development-time experience, many developers want to know how to best use all three. McClanahan's extensive history as a developer includes involvement in the Apache JServ project, which focused on implementing a next-generation architecture and feature set for the core servlet engine. He also served as technical lead for the Sun team working on the Tomcat servlet container. As a Senior Staff Engineer at Sun, he currently serves as Architect of the Java Studio Creator IDE. We met with him recently to get an update on Struts, JavaServer Faces, and the Java Studio Creator's new release.
This gives an existing Struts developer access to sophisticated, complex components, like data tables. Previously, they had to find a third-party custom tag library and integrate that into their application. Now, they're able to use such components from any vendor without changing their existing application.
For new applications, on the other hand, there is much overlap between the JavaServer Faces controller and what Struts does today. I've been encouraging the Struts community to think about what we will do next in Struts 2.0. We'll be discussing a proposal on the developer list that adds application-level functionality behind JavaServer Pages as the UI controller, and adopts some of the ease-of-use programming techniques that we see in Java Studio Creator, like the notion of a page bean that's associated with a page that handles all of the events for that page. In the current Struts world, that kind of logic is spread across three Java classes plus a page. The model that Java Studio Creator espouses and that I'm encouraging for Struts 2.0 suggests that this should be collapsed into a single class corresponding to the JavaServer Page, with a one-to-one relationship. I'm taking advantage of the way JavaServer Faces is implemented in Java Studio Creator to craft what the next generation application framework should look like.
On the other hand, something like a form submit should go to the controller in an MVC architecture. It should essentially pass through the view tier handling that says, "Aha, this particular submit button needs to be processed in business logic." That's where having a controller like Struts behind JavaServer Faces occasionally still makes sense. That's because now—instead of managing, opening, and closing tree node—you're managing acquiring a Java Database Connectivity rowset and updating the database enclosing the transaction. So, you're handling application-level events rather than user interface events. That's exactly the model that the Struts/JavaServer Faces integration library proposes: a JavaServer Faces front controller that handles user interface events, and behind that an application controller provided by Struts to ascertain which business logic to invoke.
Second, the JavaServer Faces API is going to become part of Java 2 Platform, Enterprise Edition 5.0, so that applications developed with JavaServer Faces can assume that a J2EE 5.0 application server will have JavaServer Faces already installed. That's a mark of legitimacy for the API. In the longer term, plans are to increase the functionality that JavaServer Faces provides and perhaps increase the number of standard components included in the basic API. New Developments in Java Studio Creator
Second, we'll be publishing APIs for component developers to provide rich behavior at design time. One thing that makes Java Studio Creator fun for developers is the rich design-time experience. For example, when you have a Data Table component and you drop a JDBC rowset test on it, the component instantly adapts to the columns that are in that particular rowset. This is done with a series of design-time APIs that are Java Studio Creator-specific. We have taken the standard JavaServer Faces components and created this nice design-time behavior around them. We will publish the APIs so that third-party component developers can create the same sort of rich design-time experience in the Java Studio Creator IDE for their own components. "How do I build a component?" is probably the most popular question on the JavaServer Faces forum. There is tremendous interest in components, so that's why we're focusing now on supporting the import of third-party components into the Java Studio Creator IDE.
The new changes provide a richer array of third-party components to integrate with the Java Studio Creator IDE—something that visual developers have come to expect. In addition to being a tool that offers productive design-time and development-time experiences, it also provides a set of canned functionality both within the tool and off the shelf, from other vendors. Visual developers can then greatly reduce the amount of code that they have to write. As we work with third-party component vendors and get them to integrate with the Java Studio Creator IDE, using it as their tool of choice for their JavaServer Faces components, we want to ensure a whole ecosystem around the Java Studio Creator IDE. Making Java Studio Creator Visually Intuitive
That said, another design principle requires that, whenever possible, the complexities involved in rendering HTML and dealing with HTTP transactions be hidden inside the components, so that the application developer doesn't have to deal with them. And that's where JavaServer Faces comes in: to handle complexities such as conversion and validation. In a non-JavaServer Faces application environment, the developer either has to write all of the logic, or use a framework to provide special capabilities.
In such cases, therefore, JavaServer Faces goes beyond Struts in hiding the complexities of the MVC architecture. It points developers directly to the event handlers and the parts of the Java source code that they actually need to manipulate, rather than forcing them to learn the Java APIs and tag library behind JavaServer Faces. Here's a simple example: When you look at the JSP source, a button on your JSP page looks like a custom tag. But, if you look at it in the designer, you see the actual button rendered exactly as it will be at runtime. If you double-click on the button in the designer, the Java Studio Creator IDE immediately moves you to the method that is going to be the event handler code for that particular button. You don't have to know how that all happens. You just write a few lines of code to handle the fact that this button was pressed, and JavaServer Faces will call that method at the right time for you.
We focused the initial version of the tool around the standard JavaServer Faces components. Then we're planning a set of additional JavaServer Faces components for a future version of Java Studio Creator that will focus on this visual paradigm of manipulation: what you see is what you get. And with sophisticated back-end behavior to take care of nasty things like tree control, portable tables, and that sort of thing. Developer Feedback
Developers are using Java Studio Creator everywhere, from prototyping (or rapid application development) to building departmental applications. Some developers are building more complex applications as more sophisticated third-party components become available. We have a lot to look forward to. Acknowledgements
Special thanks to Jim Inscore, Group Marketing Manager, Corporate Developer Tools, Sun Microsystems, for his contributions to this article. See Also
| |||||||||||||||||||||||||||
| |
Oracle is reviewing the Sun product roadmap and will provide guidance to customers in accordance with Oracle's standard product communication policies. Any resulting features and timing of release of such features as determined by Oracle's review of roadmaps, are at the sole discretion of Oracle. All product roadmap information, whether communicated by Sun Microsystems or by Oracle, does not represent a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. It is intended for information purposes only, and may not be incorporated into any contract.
| ||||||||||||
Print-friendly Version
What is the rationale behind the JavaServer Faces API?
The JavaServer Faces API was designed for two primary purposes. One was to provide Java developers with a standard API for sophisticated user interface components. The second was so that Java tools developers could create tools with those components that provide a rich design-time experience. The components hold information that is designed specifically for the tools to utilize. The Java Studio Creator IDE uses that information to create a very friendly environment. When composing a JSP page, you see what the components will look like when the application runs, so you can manipulate the properties of those components to a GUI mechanism, rather than having to configure everything in JavaServer Pages or Java source code.
