02
Sat, Nov
2 New Articles

Weaving WebSphere: WDSC 5.1.2 JavaServer Faces--Fifty Ways to List Your Data

Development Tools
Typography
  • Smaller Small Medium Big Bigger
  • Default Helvetica Segoe Georgia Times

"Hop on the bus, Gus
You don't need to discuss much
Just drop off the key, Lee
And get yourself free."
--Paul Simon

I love that song. I don't know anyone who doesn't recognize it, especially the chorus. It's amazing that something so simple can be so powerful.

And then there's JavaServer Faces (JSF)--complex, difficult to read, difficult to manually modify. In fact, some of its advocates claim the language was designed for its code to be generated by tools rather than by written by programmers. I'll address that issue today, but first I want to take a look at JSF itself as well as the JSF tooling available in WDSc, which is quite good for what it does.

So today, I'll cover...

  • JavaServer Pages (JSP) Models I, II, and I.5
  • JSF--Yet Another Web Framework
  • JSF Tooling in WDSc
  • Generated Code

 

JSP Models I, II, and I.5

The big debate in JSP development has centered around the "model" to use when developing applications. Until recently, the argument has centered on JSP Models I and II. For RPG programmers, it's probably easiest to explain these in reverse form:

Model II is our traditional way of doing things. We fill a buffer with data (or more, as in the case of subfiles) and then display to the user a panel that shows the data from the buffer. In most cases, this panel also contains input fields. The user enters data if needed, and then hits a button. Based on the data the user enters and/or the button that's pressed, the program decides what to do: redisplay the current panel, display a different panel, call another program, or end the current program. That's pretty much it, and we've been doing that for a long time. With JSP Model II, the JSP page takes the place of the display file, and the servlet takes the place of the RPG program. Actually, the servlet is simply a request processor that handles all sessions simultaneously. In a good design, the servlet invokes an application object specific to the session. This application object fills buffers (known as "Beans") and then displays a JSP. The JSP presents the data to the user with input fields if needed. The user optionally enters some data and then hits a button. This information is returned to the servlet, which then determines the next thing to do: redisplay the JSP, display another JSP, invoke another application object, or exit the application. Sound familiar?

JSP Model I was the first JSP model. In this model, there is no intervening servlet. Instead, each JSP page decides, based on the user action, which JSP to invoke next. This information is hard-coded in the JSP itself. For example, each button on a JSP might be hard-wired to a different JSP panel, which would then process the data from the previous JSP page. Each JSP page is responsible for pulling in its own data and for processing the results from the previous page. (Old-time NEP-MRT programmers might recognize this technique; the data coming in to your program was from the previous panel displayed.) As you can see, this leads to a very brittle application structure, without much capability of handling conditional workflow paths or even errors. Easy to use for inquiry screens, but not much good for anything else.
Then along came Struts. With Struts, you still hard-code the connection between one JSP panel and another. The difference is that you invoke an "action," which returns a value. Based on that value, you execute a JSP in a hard-coded list. Let's take a peek at a "simple" Struts configuration file (this defines a basic login panel):



  "-//Apache Software Foundation//DTD Struts Configuration 1.2//EN"
  "http://struts.apache.org/dtds/struts-config_1_2.dtd">

    
        
            name="logonForm"
            type="app.LogonForm"/>
    
    
        
            path="/Welcome"
            forward="/pages/Welcome.jsp"/>
        
            path="/Logon"
            forward="/pages/Logon.jsp"/>
        
            path="/LogonSubmit"
            type="app.LogonAction"
            name="logonForm"
            scope="request"
            validate="true"
            input="/pages/Logon.jsp">
            
                name="success"
                path="/pages/Welcome.jsp"/>
            
                name="failure"
                path="/pages/Logon.jsp"/>
        
        
            path="/Logoff"
            type="app.LogoffAction">
            
                name="success"
                path="/pages/Logoff.jsp"/>
        
    
    

Figure 1: This is the configuration file for a basic login panel.

The feature Struts developers point to as being Model-View-Controller (MVC)-compliant is the bolded area in Figure 1. The action LogonAction is invoked in response to a button being pressed on the Login page, and it will return either "success" or "failure." Based on that, either Welcome.jsp will be displayed or the user will be returned to Logon.jsp. This decouples the action from the JSPs, in that the action needn't know the exact name of the panel. This comes at the price of creating a large, complex configuration file.

Figure 1 shows the price you have to pay for just a couple of pages; imagine the complexity of a typical ERP package with thousands of screens. I call this sort of design--in which the application layout is stored in a single large file--JSP Model I.5 architecture. This relegation of workflow to a large, cumbersome configuration file is the type of thing that works really well in small, isolated applications but becomes nightmarish in large-scale applications. The Struts developers have already recognized this, and Struts 1.1 introduced the concept of "modules," which allow you to break up your applications into separate modules. However, this means the pages are hard-coded to belong to one module or another, and moving a page means at the very least modifying all the other modules that point to that page--a Band-Aid for a bullet wound, in my opinion.

Some people swear by the Struts style of development, which is fine. But because of its dependence on an external application configuration file, I consider it JSP Model I.5 architecture.

JSF--Yet Another Web Framework

So that brings us to JavaServer Faces (JSF). JSF is the latest framework from Sun. Craig R. McClanahan created Struts and is now the Specification Lead for JSR-127, the JSF specification. JSF is an interesting technology. I thought Struts was overkill; JSF is worse. Take a look at the sample listing from Sun:

 

 

  

What is your name?

    

         validator="#{UserNameBean.validate}"/>     

     

 

Figure 2: This very simple JSF page shows some extended JSF tags.

Notice that things are starting to get a little complex. To be fair, some of the new syntax is not that bad. The inputText tag is kind of nice, actually. The problem is that JSF tags don't work and play well with other tags. For example, Figure 3 has a very common JSF bug.


  
  Some more text.

Figure 3: Because of a common JSF bug, the sentences are reversed when rendered.

You would expect this to say: "Some text. Some more text." Instead, because of the intricacies of how JSF works in conjunction with JSP, you get "Some more text. Some text." And though this particular issue is supposed to be addressed in an upcoming release of JSF, it's clear to me that the specification isn't exactly ready for prime time.

People in the field have commented about the complexity of the JSF language, and at least one JSF proponent has argued that JSF is meant more for generation by tools than by people. That's an interesting way to look at things, and I'll address that in more detail in the last point of this article.

On the positive side, JSF includes a number of great UI components, such as tabbed panels, grids, and graphs. The implementation is a little complex for mere mortals, but once again, the syntax seems to be geared toward tools, not humans. On the weak side, it seems that the implementation is a little sparse on the client side, with no place for client-side validation or controller extension (the former is crucial for performance and more importantly the perception of performance, while the latter is important when implementing security and persistent sessions).
Finally, the navigation for JSF pages is the same as that for Struts. The application control file has a bunch of navigation rules, just like the Struts configuration file. It's called, not surprisingly, faces-config.xml, and it contains even more information than the struts-config.xml file. I'm not going to go into the file contents in detail; it's enough to say that the presence of this file makes JSF fit into the JSP Model I.5 architecture class.

JSF Tooling in WDSc

This is where it gets interesting. I've spent the first half of this column dissecting JSF and pointing out its flaws, so you might wonder why I even care about the WDSc support for it. One reason is that JSF is going to get better. A lot of people stand firmly behind it, and Sun itself seems to be betting the browser UI farm on this particular technology. (Is it the right one? Stick with me, dear reader, as I introduce you to some very interesting new technologies in upcoming articles. For now, let me tease you with a couple of terms like Tapestry and XUL. Stay tuned.)

The other reason, though, is that WDSc has outstanding support for it. I'm just getting my feet wet with the technology, and yet I was able to, in the space of about 90 seconds, create a Web page that went out, accessed my iSeries database, brought down records, and placed them in a table. Some vendors will sell you that particular capability for a few grand; you get it in WDSc for free.

Next, I stumbled through the tutorials for a few hours to find out how they worked. Not everything was perfectly intuitive, but after a couple of false starts, I was able to get back on track. Of course, the first thing I tried failed, but that was because my key field was a time stamp; like many tools, even WDSc is not completely comfortable with time stamps. After realizing I was perhaps overreaching a little bit, I went back to a simpler example. You can see a couple of the steps I had to perform along the way in Figures 4 through 8.

http://www.mcpressonline.com/articles/images/2002/040926%20-%20WDSC512%20JSF%20V400.png

Figure 4: This wizard allows me to define a data table. (Click images to enlarge.)

http://www.mcpressonline.com/articles/images/2002/040926%20-%20WDSC512%20JSF%20V401.png
Figure 5: This wizard allows me to modify the field characteristics for a single record.

http://www.mcpressonline.com/articles/images/2002/040926%20-%20WDSC512%20JSF%20V402.png

Figure 6: This wizard specifies page navigation.

http://www.mcpressonline.com/articles/images/2002/040926%20-%20WDSC512%20JSF%20V403.png

Figure 7: This wizard defines the parameters to pass to the next page.

http://www.mcpressonline.com/articles/images/2002/040926%20-%20WDSC512%20JSF%20V404.png

Figure 8: All of those wizards combine to create this page (and its associated maintenance page).

Without much work, I was able to quickly create a couple of pages that would generate a list of records from a file and then let me add, update, or delete records from that list (actually, I skipped the add page for the second attempt, simply to save a little time). After that initial false start with the time stamp field, it took me only about five minutes to create and configure the application, even on my little 512 MB laptop running Windows XP Home.

The application worked flawlessly, or it did once I journaled the file. I was unable to find any quick way to remove the commitment control requirement for data access, so I had to journal the file, but that's a different argument for a different day.
However, the issue that quickly surfaced was the fact that the program did almost nothing. There's certainly no validation, either on the client side or on the server side (the lack of client-side validation is actually a big issue with JSF). More problematic, though, is the fact that I'm not exactly sure where to add that code. Moreover, if I do make changes to the validation, what happens if I make a change to the UI? Do my enhancements stay in place, or do they need to be recoded? That's traditionally been one of the bugaboos of generated code, and I see no reason to think that the problem has been solved.

Generated Code

I find the code being generated by tools today very disturbing. The trend seems to be toward code that cannot be maintained by human beings. In general, the entire programming concept seems to be being wrapped in fluffy clouds of XML that can only be understood (and maintained) by tools. The first step along this line was the SOAP specification, the most bloated and overblown design I've seen in a long time. Other technologies seem to be following suit, and the JSF tag library is just one of the latest.

The generated code from a JSF-aware editor is not only cumbersome, but also non-intuitive. That's really what I find difficult to bear: the fact that in order to debug this stuff I'm going to have to dig through a bunch of different places just to get a sense of what's going on. For example, with even a simple JSF application, you're combining the XML instructions from the faces-config.xml with the new tags of the JSF tag library. You also have to understand the Java class PageCodeBase, which is generated by the IDE. None of this is necessarily insurmountable, but I've seen this sort of thing happen more than once in my career: Code builders get smarter and smarter, and programmers become less likely to think creatively, instead relying on the tools.

Typically, a tool like this can generate simple applications in almost no time, and that short time to delivery is enough to excite both developers and managers, especially managers. Fast code! For free! But eventually, classes of programming arise that don't exactly fit the tools. And by then, the programmer is entirely reliant on the code generation tools and doesn't actually know what the code does. Therefore, rather than being able to modify the code, the programmer has to either shoehorn the feature into the confines of the tool or drop the feature entirely.

So Is This the Right Direction?

That depends on what you're trying to do. If, as the title of this article suggests, you're looking for one more way to create DFU or query applications, then this is certainly a good tool for your arsenal. But even IBM realizes that most applications need some business logic, hence the EGL language that's also included (which I introduced you to in my previous Weaving WebSphere column).

EGL, however, is no substitute for RPG, and the complexity of the JSF tag language is something I can't overlook, especially when more elegant solutions are available. For now, I just don't see JSF as the next great evolutionary step in Web application development.

Joe Pluta is the founder and chief architect of Pluta Brothers Design, Inc. He has been working in the field since the late 1970s and has made a career of extending the IBM midrange, starting back in the days of the IBM System/3. Joe has used WebSphere extensively, especially as the base for PSC/400, the only product that can move your legacy systems to the Web using simple green-screen commands. Joe is also the author of WDSC: Step by Step, Eclipse: Step by Step, and E-Deployment: The Fastest Path to the Web. You can reach him at This email address is being protected from spambots. You need JavaScript enabled to view it..

Joe Pluta

Joe Pluta is the founder and chief architect of Pluta Brothers Design, Inc. He has been extending the IBM midrange since the days of the IBM System/3. Joe uses WebSphere extensively, especially as the base for PSC/400, the only product that can move your legacy systems to the Web using simple green-screen commands. He has written several books, including Developing Web 2.0 Applications with EGL for IBM i, E-Deployment: The Fastest Path to the Web, Eclipse: Step by Step, and WDSC: Step by Step. Joe performs onsite mentoring and speaks at user groups around the country. You can reach him at This email address is being protected from spambots. You need JavaScript enabled to view it..


MC Press books written by Joe Pluta available now on the MC Press Bookstore.

Developing Web 2.0 Applications with EGL for IBM i Developing Web 2.0 Applications with EGL for IBM i
Joe Pluta introduces you to EGL Rich UI and IBM’s Rational Developer for the IBM i platform.
List Price $39.95

Now On Sale

WDSC: Step by Step WDSC: Step by Step
Discover incredibly powerful WDSC with this easy-to-understand yet thorough introduction.
List Price $74.95

Now On Sale

Eclipse: Step by Step Eclipse: Step by Step
Quickly get up to speed and productivity using Eclipse.
List Price $59.00

Now On Sale

BLOG COMMENTS POWERED BY DISQUS

LATEST COMMENTS

Support MC Press Online

$

Book Reviews

Resource Center

  • SB Profound WC 5536 Have you been wondering about Node.js? Our free Node.js Webinar Series takes you from total beginner to creating a fully-functional IBM i Node.js business application. You can find Part 1 here. In Part 2 of our free Node.js Webinar Series, Brian May teaches you the different tooling options available for writing code, debugging, and using Git for version control. Brian will briefly discuss the different tools available, and demonstrate his preferred setup for Node development on IBM i or any platform. Attend this webinar to learn:

  • SB Profound WP 5539More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.

  • SB HelpSystems ROBOT Generic IBM announced the E1080 servers using the latest Power10 processor in September 2021. The most powerful processor from IBM to date, Power10 is designed to handle the demands of doing business in today’s high-tech atmosphere, including running cloud applications, supporting big data, and managing AI workloads. But what does Power10 mean for your data center? In this recorded webinar, IBMers Dan Sundt and Dylan Boday join IBM Power Champion Tom Huntington for a discussion on why Power10 technology is the right strategic investment if you run IBM i, AIX, or Linux. In this action-packed hour, Tom will share trends from the IBM i and AIX user communities while Dan and Dylan dive into the tech specs for key hardware, including:

  • Magic MarkTRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now!  Request Now.

  • SB HelpSystems ROBOT GenericForms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.

  • SB HelpSystems ROBOT GenericIT security is a top priority for businesses around the world, but most IBM i pros don’t know where to begin—and most cybersecurity experts don’t know IBM i. In this session, Robin Tatam explores the business impact of lax IBM i security, the top vulnerabilities putting IBM i at risk, and the steps you can take to protect your organization. If you’re looking to avoid unexpected downtime or corrupted data, you don’t want to miss this session.

  • SB HelpSystems ROBOT GenericCan you trust all of your users all of the time? A typical end user receives 16 malicious emails each month, but only 17 percent of these phishing campaigns are reported to IT. Once an attack is underway, most organizations won’t discover the breach until six months later. A staggering amount of damage can occur in that time. Despite these risks, 93 percent of organizations are leaving their IBM i systems vulnerable to cybercrime. In this on-demand webinar, IBM i security experts Robin Tatam and Sandi Moore will reveal:

  • FORTRA Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:

  • FORTRAManaging messages on your IBM i can be more than a full-time job if you have to do it manually. Messages need a response and resources must be monitored—often over multiple systems and across platforms. How can you be sure you won’t miss important system events? Automate your message center with the Robot Message Management Solution. Key features include:

  • FORTRAThe thought of printing, distributing, and storing iSeries reports manually may reduce you to tears. Paper and labor costs associated with report generation can spiral out of control. Mountains of paper threaten to swamp your files. Robot automates report bursting, distribution, bundling, and archiving, and offers secure, selective online report viewing. Manage your reports with the Robot Report Management Solution. Key features include:

  • FORTRAFor over 30 years, Robot has been a leader in systems management for IBM i. With batch job creation and scheduling at its core, the Robot Job Scheduling Solution reduces the opportunity for human error and helps you maintain service levels, automating even the biggest, most complex runbooks. Manage your job schedule with the Robot Job Scheduling Solution. Key features include:

  • LANSA Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.

  • LANSAWhen it comes to creating your business applications, there are hundreds of coding platforms and programming languages to choose from. These options range from very complex traditional programming languages to Low-Code platforms where sometimes no traditional coding experience is needed. Download our whitepaper, The Power of Writing Code in a Low-Code Solution, and:

  • LANSASupply Chain is becoming increasingly complex and unpredictable. From raw materials for manufacturing to food supply chains, the journey from source to production to delivery to consumers is marred with inefficiencies, manual processes, shortages, recalls, counterfeits, and scandals. In this webinar, we discuss how:

  • The MC Resource Centers bring you the widest selection of white papers, trial software, and on-demand webcasts for you to choose from. >> Review the list of White Papers, Trial Software or On-Demand Webcast at the MC Press Resource Center. >> Add the items to yru Cart and complet he checkout process and submit

  • Profound Logic Have you been wondering about Node.js? Our free Node.js Webinar Series takes you from total beginner to creating a fully-functional IBM i Node.js business application.

  • SB Profound WC 5536Join us for this hour-long webcast that will explore:

  • Fortra IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn: