A test-drive of Java Studio Creator

JavaServer Faces was developed with IDES and rapid development of Web applications in mind. But is JSF living up to its promise? Can an IDE built around JSF potentially improve our productivity? Can such a tool help us create and deploy functioning Web applications faster than currently available options? The best way to answer this question is to test-drive one of the current IDEs that support drag-and-drop JSF development and attempt to develop a real Web application, a task I describe in this article.

My experiment includes the following particulars:

  • The tool selected:Sun Microsystems’ Java Studio Creator (JSC), a choice that, of course, is debatable. Reasons for this selection include fairly good reviews on the Web, its selection as runner-up for Developer.com’s 2005 Development Tool of the Year (behind Eclipse, so it’s perfectly understandable why it was only a runner-up), and, price ($99). There are a number of other tools in this space, many of which, based on a quick review, are worthy of deeper exploration. Some don’t provide drag-and-drop functionality, but have other nice features. These IDEs include:
    • Borland JBuilder Enterprise Edition 2005
    • Eclipse with Exadel Studio Pro
    • Eclipse with Nitrox JSF
    • IBM Rational with JSF support
    • Macromedia Dreamweaver with JSTL and JSF extensions
    • MyEclipse with JSF Designer
    • Oracle’s JDeveloper
  • The project:A simple Web application that searches an employee database.
  • The developer: I am a reasonably competent developer with infrequent flashes of astonishing brilliance balanced by equally infrequent flashes of profound stupidity; lots of Java development experience; quite a bit of experience developing Web applications with servlets, JavaServer Pages/JSP Standard Tag Library, and Struts; and a basic understanding of JSF. I’m fairly skeptical about using IDEs for real software development. Before starting this project, I spent a few hours playing around with JSC to get somewhat familiar with its capabilities.

Now that the particulars are out of the way, I’m ready to start developing.

Time: 8:00 a.m. I fire up JSC on my laptop at the coffee shop. The first screen looks like this (it may look a little different on your machine, depending upon how you’ve configured your panels):

Figure 1. Click on thumbnail to view full-sized image.

I select Create New Project. I type JSFExperimentfor the project name and click the OK button. The initial design project comes up and looks like Figure 2.

The window resembles the NetBeans IDE, of course, because JSC is built on NetBeans. In the bottom left panel is the actual page I’m working on, with tabs for a visual layout and the page source.

To the left is a panel that allows me to navigate through the pieces of my Web application, including the pages and the session and application beans. The top right panel has several tabs, which I explain in more detail below. By default, the project is created with a single JSP page.

The JSC download comes with the platform edition of Sun Java System Application Server, which eases the deployment and testing of JSF applications developed with the tool. Alternatively, we could install Tomcat and add/configure JSF support, but having a Web container included with the tool, with built-in JSF support is certainly helpful. There’s also a SQL database server (PointBase) installed to support creation and testing of Java Database Connectivity (JDBC) functionality. In addition, a JDK is included along with plenty of documentation. All this makes for a large download, but the cost of a few (hundred) MB is offset by convenience.

I want my simple application to have two pages: a search page that sets up my query, and a results page. I go to the Project Navigator tab, right-click on Page1, and rename it search.Then I right-click on the Web Pages page, select New, then Page, and type resultsin the resulting dialog box. I now have a Web application with two pages. Now I will add some components and set up basic navigation between the pages.

In the search page, I want some text, a dropdown list for selecting search criteria, and a submit button. So, I select the Palette tab, then JSF Standard Components, and drag an Output Text, a Dropdown List, and a Button component to my search page. After placing the components, I select the Output Text and Button components, then select the Properties tab, and edit the Value property for each of the components to change the output text. After I complete these tasks, the page looks like this:


Figure 2. Click on thumbnail to view full-sized image.

For the results page, I drag an Output Text component and a Data Table component. For the Output Text component, I change the Value property in the Properties tab under in the Palette window to edit the display text. You’ll see how to customize the headers for the Data Table component below.

Now is a good time to set up basic page navigation. One approach is to right-click on the search page’s design page anywhere outside one of the components and select the Page Navigation action. A graphical navigation editor then displays in the design panel. If I click on the search page, it will enlarge, and I can drag a navigation line from the Button component to the results page. Once I’ve done that, the name of the action is selected; this is a good time to rename it. I call it doSearch.The navigation editor now looks like this:


Figure 3. Click on thumbnail to view full-sized image.

If I click on the Source tab in the design panel, I’ll see the faces-configfile display with navigation rules defined that are consistent with what I just completed in the editor. JSC also supports dynamically controlling page navigation, which I do not cover in detail here.

This has all been pretty easy so far–almost too easy. Could it be possible that I’ve created something that actually works? All I need to do to find out is select Build Project from the Build menu in the top menu bar, then Run Project from that same menu. Running the project will start the Sun application server with my built and deployed Web application, and fire up the default browser with the URL pointing to the Web application. Sure enough–I see this page:


Figure 4

When I select the Do Search, button I see this page:


Figure 5

It worked!!! It’s now 8:45 a.m. I haven’t written a single line of code yet and I have a working (although simple and, admittedly, completely worthless, since I’m not accessing the database yet) Web application. If I had not documented each step in the process, I’m quite sure I could have done this a lot faster. Plus I had to stand in line for a while to get a bagel.

Now things are going to get a little more interesting. I want my application to talk to a database. JSC comes with a PointBase database server installed, which is very cool. However, for this experiment, I want to connect to a different database. I want to use the Apache Derby open source embedded database. I also just want to connect to a database that’s already been created. My database is simple and just contains one employees table. I won’t debate the merits of this particular choice for this particular application; I just want to see how easy it is to use a relatively arbitrary database with JSC.

So, from the top menu bar, I select Data, then Add Data Source, add the JARs I want to use and JDBC driver information (after a bit of refreshing on how to set up the Derby URL to point to a specific place in the filesystem):


Figure 6. Click on thumbnail to view full-sized image


Wow, that was easy. I wonder if I actually did anything. I hit the Test Connection dialog and receive:

IMAGE: images/jw-0704-jsf7.jpg 425 135 CENTER

Figure 7

That’s encouraging. I attempt to view the tables in my database (I actually only have one) from the Server Navigator tab and I see the following–even more encouraging:


Figure 8. Click on thumbnail to view full-sized image.

Time: 9:00 a.m. I usually don’t order the extra large black coffee–I usually just get wimpy mochas that don’t have nearly the caffeine level. My head feels a little funny, but I am also feeling extremely productive. It’s probably too early to tell yet whether that feeling is just an illusion.

I haven’t covered (and won’t in detail) support for page layout. However, JSC offers two options for page layout: grid layout, which places components at an absolute location on the page; and flow layout, which lays out components left to right on the page. I switch from the grid layout (the default, which uses absolute positioning on the page) to a flow layout, which seems a bit more adaptable and less Visual Basic-like. A couple of JSF components also support the laying out of subcomponents. This functionality and JSC’s support for easily using stylesheets offer many options for controlling layout, a subject that could be the focus of a future article.

I start using the database by attempting to populate the dropdown list on the search page. When the page loads, I want the list to be populated with only those employees with a position equal to MANAGER. Then I want to allow searching by a particular manager and display attributes for those employees in that manager’s department.

To do this, I select my results page, then go to the Server Navigator window, select the EMPLOYEE table, and select the Add to Page context action. Now I double-click on the employeeRowSet tab and get a panel that graphically displays the table rows. I can unselect the columns I don’t care about (specifically, all except LNAME and DEPT). This creates a query that returns all the rows from the table with two columns in each row. I only want to return the employees that are managers, so in the query display panel I add the following criteria


Now the query editor looks like this:


Figure 9. Click on thumbnail to view full-sized image

I right-click on my DropdownList in my JSP design page and select Fill List from Database. In the resulting dialog, I select EMPLOYEE.DEPT for the Value field, and EMPLOYEE.LNAME for the Display field. If this works correctly, an abcshould display in the dropdown list indicating that the data type is a string. This happens, and all seems to work properly.

OK, I can’t wait. I haven’t written a line of code yet, with the arguable exception of one WHERE clause. Have I produced anything that actually works? I select the File menu, then Save All to save my project; then, from the Build menu, I select Build Project. If there are no errors, there should be a dist/under a directory matching the project name containing a war file—which occurs as expected.

Now things get a bit tricky only because of my experimentation with my database of choice. The embedded Derby JDBC driver I selected allows only one connection to a given database, which I’ve already made in the course of working with the database within JSC. So, if I run the project (which would work fine with a typical database by just firing up the default browser from within JSC with our Web application URL), I’ll receive an exception indicating that the page couldn’t establish the database connection because it’s already been established. Alternatively, I could shut down JSC, copy the war file to Tomcat or some other Web container that has JSF support installed, and start the Web application. I may need to remove the db.lckfile to successfully establish a new connection (before I send this Web application to production, I’ll make sure I invoke the Derby shutdown URL to properly clean things up).

If you don’t have another server configured with JSF support yet, a reasonable (and quicker) option is to just use the Sun application server that comes with the JSC installation (there’s a reason why it’s such a big download). On a Windows box, from the Start Menu, select the Run submenu, then Sun, then J2EE 1.4 SDK, then Start Default Server to start the server. For a project named JSFExperiment, the URL should be: http://localhost:18080/jsfexperiment/.

It works! I now have a Web application with a dropdown that’s actually populated with real data from a real database!

Now I begin working on the page that gives the results. For the Data Table component in the results page, I select the EMPLOYEE table from the Server Navigator, and drop it on to the Data Table (note the entire Data Table needs to be selected). In the query editor, I unselect all columns except for LNAME, MI, FNAME, and POSITION. Then, in the query string, I add WHERE APP.EMPLOYEE.DEPT=? as the criteria.

I want to customize this table a bit, similar to what I did earlier, by removing some of the rows and renaming the column headers. In the Application Outline panel on the left side of the screen, I right-click the Data Table component, and select Table Layout. In this dialog I can customize the display strings for the column headings:


Figure 10. Click on thumbnail to view full-sized image.

I want to populate the Data Table based on the value of the dropdown selection. Finally, I’m at the point where I can write a bit of source code! But, it’s not much.

I want to populate a value in the session bean (the current menu selection) to make it available in the next page. To do that, in the Project Navigator panel, I select Java Sources, then databoundcomponents, then SessionBean1, and then select Add, then Property from the Context Action menu. I name the new property departmentand give it a data type of string.

Now I want to populate this value when the dropdown list changes. To do that, I select the Page1.jsp tab and double-click on the Dropdown List component. This is interesting–the event-handler method stub isn’t created for the dropdown1_processValueChange()method until the first time you double-click on the Dropdown List component. The Page1 source code displays in the Editor area, and the cursor is placed inside the body of the dropdown1_processValueChange()method.

I add a bit of code to the method body:

try {
} catch (Exception e) {
log("Exception selecting departments", e);
error("Exception selecting departments " + e);

In the constructor for the results page, I use this value in my query:

try {
dataTable1Model.setObject(1, getSessionBean1().getDepartment());
} catch (Exception e) {
log("Exception selecting managers", e);
error("Exception selecting managers: " + e);

I rebuild the Web application and see this results page:


Figure 11. Click on thumbnail to view full-sized image

It all works! The time is now 9:45 a.m. In less than two hours, I’ve completed a Web application with a deployable WAR that talks to a database and actually does something useful. Again, I believe the amount of time would have been much less if I weren’t recording my steps along the way. Plus, people at a neighboring table have been distracting me with their proposed solution for world hunger.

A few conclusions from this experiment:

  1. To create a basic, functional Web application that queried to a database, I didn’t write a single line of code!
  2. When I did get to the point of adding some code (to add the results of a database query to a session bean and make them available to the next page) I was working with generic Web application concepts and didn’t need to know or care about the intricacies of JSF.
  3. If I had to produce this application immediately using JSC, without the chance to become familiar with its features, would I have developed faster than if I had just used some combination of servlets, JSP/JSTL, and Struts? Definitely not. Would I have developed faster the second time around? Absolutely.

I’d like to qualify some of the conclusions above. Many issues are being hotly debated in the JSF community, but most of these are related to JSF itself rather then the fact that a JSF application can be developed with an IDE. Some examples of these issues: Because of JSF’s use of JavaScript and hidden form fields, some problems result when developing automated tests for JSF applications with tools like jWebUnit and WebTest from Canoo. Plus, JSF 1.1 isn’t good at handling duplicate form posts (although that should be improved with JSF 1.2). Also being sorted out is the precise relationship of JavaServer Faces to Struts.

For my experimental project, I wanted to start with a static page mockup developed by an imaginary graphic design team in conjunction with imaginary informed representatives from an imaginary user community, and then populate that page with dynamic content. I’ve found this to be a pretty good way to at least start converging on UI functionality before wasting development time on something the users didn’t really want. JSC documentation describes a fairly straightforward-sounding way to do this via the Add Existing Item option from the File menu. However, all the options under this selection appeared to be disabled. Was this feature just not quite finished in my JSC version? I don’t know and couldn’t seem to get the feature to work. The clock was ticking and I had to move on. I assume that in some future JSC version, this feature will be available and will be solid, because it’s just too useful not to have.

For this article, I didn’t have the chance to detail many JSC features. One feature that is particularly interesting is JSC’s support for easily wiring up a JSF Web application to Web services. The quick-and-dirty application I developed doesn’t attempt to hide database details. Being able to easily connect to Web services is going to be useful.

I didn’t intend for this article to offer an endorsement of any particular IDE, but I came away impressed with JSC. Sun’s had its share of hard knocks in recent years. It’s nice to see them produce such a high-quality product. If the other tools in this space are anywhere close to this level of quality, things look promising for the future of JavaServer Faces

Leave a Reply

Your email address will not be published. Required fields are marked *