"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):
|
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:
|
LATEST COMMENTS
MC Press Online