Web Application Checklist
[Previous] [Main]

Java Server Faces Web Application - Checklist
Adding a Web Client to JGuiGen
July 2004


First - what is JGuiGen? JGuiGen is a program generator for single SQL table edit system. JGuiGen starts by building a data dictionary from the meta-data obtained from a SQL backend. A developer then edits this data dictionary to tell the system more about each column in the table. A rich client - client/server application is then generated from this information. Applications generated by JGuiGen have the following characteristics: CRUD + FLARES. CRUD is a fairly standard acronym and FLARES is my own.

CRUD + FLARES

C - Create (Add rows)
R - Read (view)
U - Update (with validations)
D - Delete (or mark as "inactive")

Plus

F - Filter (Build, save, execute SQL WhereClauses using a QBE)
L - List (JTable of editable rows in the SQL table, click a row to edit the row)
A - Assist (Help Screens)
R - Report (JFreeTable - report on any sets of the JTable columns)
E - Export (Print any screen)
S - Special custom code can be accessed from the menus.

My intention is to generate a Web Application at the same time. This document lists the issues I need to consider as I generate the code.

What I am trying to do here is impossible and I know that. The issues involved in developing software vary from project to project and hence there can be no generic list of issues. This is especially true of larger systems where the interaction between the pieces can become a unique tangled nightmare.

So why am I writing this checklist? As I developed the JGuiGen Rich Client code generator I discovered that in addition to horizontal complications (between a given edit screen and the rest of a larger application), there were a large number of vertical issues. As I developed the code, I kept finding that there was one more level I needed to take care of. For example you can start with a basic edit screen, add internationalization, add accessibility code for handicapped users, add logging, add saving and using personal preferences, unit testing, etc. The list goes on and on.

Now I want to use the same core application and generate a Web version of the basic edit system that JGuiGen generates. Part of doing this is trying to get a handle on the vertical levels of code before I start coding. A number of these issues are web specific and some echo the list I developed for the rich client application. I expected a long list, but this has gotten out of hand.

I have attempted to stay away from the stock items like usability and robustness and concentrate on concrete items that I can see in the code. (I can't see "usability" - I know it is there, I just can't see it. I can see if the code is internationalized.) I do take special care that applications act like "standard applications." I didn't know this was a java issue until I found that you press tab to get out all components except two and that writing code that gave you a drop-down list for states of the United States and worked right was a real pain.

Here is the list I have developed so far for a web app that uses Java Server Faces.

The "Proposed/References" Column contains the general path I intend to take at this point and a book/page number reference for information. The last column "Required Code/Do" indicates if this section is generated by JGuiGen or is used as example to get my code to run on the web. Many of the points marked "EXAMPLE" will be replaced by something that is already in place when someone actually uses the JGuiGen code. For example, I need an AppServer and will be using Tomcat 5.0. Other people may already have WebLogic or Sun's Server already in place. The JGuiGen code should run in their environment just as well. The "Do" portion will be either "Do" or "Not Yet" to indicate things I will be actually doing in the first generation or things that will be delayed.

Note: This was a table in my original document. It is more jumbled this way, but I don't have time to fix it right now.

No.   Checkpoint   Proposed/ References   Required Code/Do   
1,   Decide on an AppServer and configure it to the Java Server Faces servlet and recognizes JSF files   Tomcat 5.0 - all three JSF books - Geary 4 is best   Example Do   
2.   Model the application   By Hand or using open source ArgoUML - www.argouml.tigris.org   Example Done - by hand   
3.   Implement a Bug Tacking/Issues system available to the world   ???   Example ???   
4.   Decide upon a backend SQL database    I will test with several - PostgreSQL, MySQL, MS SQL Server, Oracle, hsqldb   Example Do Postgres   
5.   SSL Tunneling to SQL database   Hacking Exposed Java - book and code at hackingexposedjava.com   Example Not yet   
6.   Encrypt username/password that accesses SQL Backend    Leaning toward taking an encrypted string from the deployment file and obtaining username/password and more. An obfuscated class with no source read and decrypt this string. Hacking Exposed Java   Example Do (Must do for Rich Client)   
6.   Connection pooling to a SQL database   Tomcat's pooling (Commons DBCP) Notes: There are two major things - the XML file to set up the pool and the java code that opens and closes connections and insures that the connection is not closed twice. Geary p 435   Example Do   
7.   Authorization - JAAS, LDAP, etc. LDAP repository. Geary - p 438   The alternatives are to use options in JAAS (native security, keystore security, etc.)a user database table, register users with Tomcat or LDAP. LDAP would also involve using JNDI to access the information in the Database username/password with levels of encryption. Leaning toward user database access - similar to Rich Client JGuiGen   Example Do   
8.   Filter to redirect to Login if protected pages are access by user who are not logged in.   [Bergsten Book - page xx/ Kurniawan Book - page xx, Geary book p. xx]    Required Do   
9.   Decide on session state issues. Server Side, client side, stateless(?), Default time to auto-disconnect etc.   Server Side state - 30 minute timeout, 30 second abandoned pooled connection   Example Do   
10.   Decide on how much to configure outside the application and where to put the configuration files (session level, application level, container level, web.xml file, faces_confi.xml file, my own xml file etc.   Planning to move several things from the current JGuiGenINI.xml setup file to the face_config.xml file. (Geary p 458)   Required Do   
11.   System to Notify users if the system in down   Two methods - A) the existence of a special text file with a message about when and how long and B) a phaselistener that detects that the database is unavailable. Users are redirected to an error page (Bergsten p ??)   Example A-Do B-Not Yet    
12.   General Error redirection - send users to a custom page, log info, send email to support   Bergsten - page xx, JSP Sample code in Tomcat 5.0 "errorPage". Geary p. ??   Example Do   
13.   Other Two way communication between system admin/developers and users Some items here are duplicated with standalone items.   - To User - Special page that is viewed once (and from a menu) when the application is updated - History.html in JGuiGen Rich Client -   To User - Help System - everywhere -   To User - notice system is down (mentioned above) -   To System Admin - auto email about errors and intrusions -   To System/Developer - voluntary emails - include log file (suggestions and bug complaints) -   Formal Bug tracking   Example Do some now   
14,   Decide on Synchronizer Token - Should each page generated have a unique random token and then be used when the page is returned to make sure that the same page is not submitted multiple times.   May need to do this. The code is in Core J2EE Patterns Since edits use a timestamp check already, this may not be needed    Required Check Further   
15.   Decide on row versioning - Being able to run reports or see how the data looked at any previous time is powerful, but adds complexity   PostgeSQL has automatic row versioning.   Not planned at this time   
16.   Decide on UNDO code   Undoing the kind of edits provided by JGuiGen would require a lot of work   Not planned at this time   
17.   Filter for compression if available in browser   Bergesten Book - page ?? - Will probably do this since I intend to send fairly large tables.   Example Do   
18.   Caching at the server side in addition to Tomcat internal caching   Java Open Source Programming Book - page 198 talks about OSCache that plugs in with no extra code and caches graphics, pages and snippets.   Example Not Yet   
19.   Filter to log user traffic for analysis   Clickstream from opensymphony.com is open source and plugs in as a filter. It logs session traffic patterns to a text file   Example probably   
20,   Fit application inside a corporate framework to match the look and feel of other pages on a larger site. See Note 1 below   Tiles, Sitemesh and home grown systems are widely used. I will use Tiles from the Jakarta Struts project. Open source for Java - about Sitemesh p ??, Bergsten p. xx and Geary p 315   Example Do   
21.   General Security, anti-hacking, anti-hijack issues (SSL, hiding database password, hiding user passwords, anti-sniffing, etc.)   Geary p 109 and p480 Hacking Exposed Java/J2EE - whole book   Required Do   
22,   Make sure application works with Proxies and through firewalls   Geary    Required Do   
23.   Use a CSS    Make sure pages work without the CSS, Validate with W3C.org, make sure users can override. Will start with the sample CSS from the Accessible Web Sites book   Example Do   
24.   Set up proper character set encoding if some users are not using LATIN-1   Don't think this is an issue here   Example Not Yet   
25.   Pay attention to code maintenance/enhancement issues   Especially important for a code generator like JGuiGen. JGuiGen uses an data dictionary based on the SQL tables being accessed.. The second time you create the code, it marks each section that is NEW or CHANGED because there was a change in an SQL table. Some effort was made not to overwrite code that was most likely to have been hand tweaked.   Required Part of JGuiGen    
26.   Authorization issues   JGuiGen uses roles. Users belong to different roles. Each role has permissions about what it can do to each edit page . Permissions are View, Edit, Add, Delete (remove from active statue). Geary p 485. Where role membership is stored and where role permission are stored is still under research   Required Do   
27.   Internationalization (I18N) and Localization - Resource Bundles and Message Bundles   This issue was addressed by JGuiGen by creating a table of all prompts, their current values and their translation. All property files are generated out of this table. The table is automatically updated with the application uses a prompt that is not in the default properties file. Many items (such as hot keys, patterns for "proper" telephone numbers) are stored in the resource bundles Geary talks about I18N p 431. See JGuiGen documentation at halepringle.com for more info.   Required Do (much is done)   
28.   W3C HTML 4.0 compliance    Must handle at least IE, Netscape and Mozilla   Required Do   
29.   Accessibility (A11y) issues   -   Not covered much in any of the three books I have pored over on JSF. Some issue I will deal with are listed in Note 2 below -   Bobby Compliant Accessible Web Sites by Thatcher et al   Required Do   
39.   Collect and write Custom JSF Components for standard Business Needs - See Note 3 below   For example - date component from Bergsten p xx, Tree component from Bergsten p 301, Tabbed pane from Geary p 401   Required Do   
31.   JSF Converters   Except for those associated with custom components, I can't think of anything I will need to do here. Geary p 152 had information about putting global messages into a table for HTML screen formatting purposes. I'd like to put most of the error message in the global errors lists. This required getting a reasonable name for the component that failed.   Required Do   
32.   JSF Validators   Syntactical validation - I will probably bind most of the validations to special methods in the data bean. I am already doing that with the Rich Client version. I will use as much client side validation (backed up by server side) as I can. I see a need for pattern matching and regex expression matching validator that takes info from the I18N properties file.   Required Do   
33   Client Side syntactical validation   Geary p. 600 shows using Struts client-side (JavaScript) validation classes). He also shows (p 615). Using Jakarta Common client side scripting classes.   Example Do   
34.   Program Logic (finally)   Key screens and the logic behind them are as follows: -   Login -   List of Editable Tables -   QBE filter screen -   Scrolling, pageable list of rows to edit (Geary 591 and Bergsten p xx) -   Data Entry Screen - popup Geary p 587) -   Error Screen (Geary 595) -   Help Screens -   Console - list for SQL commands that ran   Required Do   
35.   Page Navigation   Part of JSF - Issue how to test for completeness.   Required Do   
36.   Multi-user Safe and Transaction processing   JGuiGen generates code that uses JDBC and timestamps to make multi-user safe updates. Since it is basically a one-table-at-a-time edit system it should not need transaction processing.   Required Done   
37.   Using and Saving User Preferences   Session level userPref bean - either serialized or saved to a SQL backend. This is required for Accessibility.   Required Do   
38.   Web Services - Using SOAP and WSDL   Geary pg 482 gives the code to interact with Amazon using SOAP   Example Not yet   
39.   Rendering on cell phones and PDAs (J2ME and MIDP)   Geary p 279 has a chapter on doing this and has several JSF renderers for standard components.   Example Not Yet   
40.   Deployment Issues - auto-build to a WAR file - run in classes and Jar/War   Will be using an Ant build script (Geary p 39 and 623) Johnson (J2EE Design and Development) want three levels - development, test, and production). I will probably just use two.   Example Do   
41.   Uploading and displaying graphics   Geary p 562 has an upload bean and the filters to make this happen.   Example Not yet   
42.   Logging - Tomcat and Application   There will be three levels of logging -   Tomcat container level -   Application - security log -   Application - user log The security log will contain entries about security violations (Hacking Exposed - Java/J2EE)   Required Do   
43.   Automatic regular parsing of logs and sending messages to System Admin of important issues.   This should be done at least on a daily basis and should generate email to appropriate parties. I will probably switch JGuiGen to Commons logging so that sites with Log4j can use the code without changes. It currently uses Sun's logging. Commons uses Sun's or Log4J or whatever it find.   Example Not Yet   
44.   Simple Ad Hoc Reports   No info yet -available in the rich client version. I would like to see it available in the Web version, but it will have to wait.   Example Not yet   
45.   JUnit Tests   Generated for the rich client version. I will generate more   Required Do   
46.   Help System   Mentioned above, but critical to a business application. I don't know if the Java Help system extends to the web   Required Do   
47.   Version Control   CVS - but may look at Subversion and issue tracking build it   Required Do (done)   
48.   Documentation   There are level here. The help system, the Data Dictionary printouts, interal notes and JavaDocs are automatically part of the system. Install notes, developer notes etc. will be on the web site   Required Do   
49.   Robust - See Note 4 for a list of items that need to be checked.   This could take forever   Required Do   
50.   Scalability issues   I'm not worrying about clustered servers with the JGuiGen.   Not Done   
51.   Complex multi-table edits   Not with JGuiGen. It can be done with a little tweaking, but it not a standard part of what I am doing.   Not Done   
52.   Backup Issues   Not with JGuiGen    Not Done   
53.   MVC - See note 5 below   I want to use as much of the code as I can between the two types of applications.   Required Do   




 

Note 1: It would be nice the buttons in the main frame work were all attached to a general PropertyChange listener that I could hook into regardless of the application in the main body content portion of the screen. The idea here is to have the menu navigation buttons in the menu part of the screen (in a navigation Tile for example) notify my application that it should check for unsaved changes when the user tries to navigate somewhere else on the site without saving.  


Note 2: Accessibility issues (A11Y) - These are important to me so I will spend some time on them. Here is a partial list of some items I will be looking at.  
-Invisible links to main content section of web pages (the blind users can just over banners and navigation stuff)  
-Alt= "??" on all graphics navigation buttons  
-Required fields start with an * (and perhaps more)  
-Tooltips available everywhere  
-Will try hot keys - they are supposed to be available  
-Making sure pages serialize well for voice browsers  
-Using OutputLabels instead of OutputText for prompts to editable fields.  
-Make sure data tables have the internal Ids so that blind users can know where they are.  
-Make sure custom components with multiple parts make sense to voice browsers. (e.g. a date components with three parts - a day, a month and a year input fields - might sound like a data input fields and two unknown input fields to a blind user.  

Note 3. I am interested in Business Applications and there are about a dozen standard components that need to be dealt with gracefully and consistently. The ones that JGuiGen - Rich Client deal with are listed here. I will try to do most of these in the JSF version.  
a. Tree component - Bergsten p 283  
b. Tabbed Pane - Geary 401  
c. Date/Calendar - Kerniawan - p 308  
d. Time  
e. Phone number  
f. SSN  
g. Credit Card - Geary  
h. Email address - Jakarta commons  
i. State - e.g. Florida  
j. Postal Code - generic  
k. Currency  
l. Decimal number (fixed number of decimals)  
m. Integers (positive only or positive/negative)  
n. Text - Validated against a regex  
o. Text - validated against a pattern (e.g. JFormattedTextField)  
 
Note 4. Robustness - I said I wouldn't list this one, but what the heck. Most of these were listed above, but some of the on/off issues need to be pulled out and looked at as a list.
a.Browser Safe  
b.OS Safe  
c.Screen Resolution safe (resizes if user wants to)  
d.Uses and saves user preferences  
e.CSS on/off safe  
f.Cookies on/off safe  
g.Firewall safe  
h.Proxy safe  
i.W3C compliant  
j.Graphics on/off safe  
k.Multi-user safe  
l.Thread safe  
m.Bobby - compliant (Accessible)  
n.I18N - labels, currency, dates, etc.  
o.JavaScript on/off safe  
p.Ability to send messages to developer/maintainer  
q.Easy to learn and use  
r.Keyboard shortcuts for power users and handicapped  
s.Data safe - low corruption rate, backups automatic.  
t.Multiple sessions by one user at the same time safe  
u.Safe for other applications on the user's PC  
v.Safe for other applications on the server.  
w.Scalable - within reason  
x.Portable - easy to port - not completely portable from start.  
y.SQL backend - easy to port  
z.Hacker resistant  
 
Note 5. Model View Controller (MVC) Issues. Every book I read on MVC has a different take on what MVC actually is. For example Johnson in his book on J2EE Design and Development wants data in the Model classes and all business logic in some other set of Classes. Bergsten in his book on JSF, indicates the model is just the data bean - with setters and getters, etc. I am working to use as much of the code as I can between the rich client application and the JSF web application. In order to do this I am refactoring the rich client code. Right now many of the classes process information and if they run into a problem, the pop-up a JOptionPane and tell the user about it. I am refactoring so that most of these store their messages in a msg variable which has a getMsgs() getter. The major action methods now return short strings and the calling method contains a call to getMsgs() if the code returned is "error". The major parts of the rich client application (as it is currently beting refactored) are as follows:
- As the application is started a Model class is instantiated that calls the setup routines such as the login method, takes parameters from an XML INI file, connects to the database. It contains utility routines. This would be the equivalent of an Application bean in the JSF framework. The login routine creates a UserBean with information about the current user. The Model class also contains a link to a TableModel class that is specific to the SQL table to be edited.
-A main application class for each edit screen is also instantiated. It takes a reference to the Model class as a parameter. This class creates a dataRow bean and calls the TableModel class to obtain data to fill the dataRow bean.. It calls the View class. The main class is part controller and part model by most MVC definitions.  
-A View class takes Model and the dataRow bean is parameters. It contains the instantiation of Swing components, a method to take data out of the bean and put it into the appropriate components, a call to a Layout class and methods to create a new dataRow bean and fill it with the data from the components. The listeners for actions like "Save" and "Add" are here. They activate methods in the main class.  
-The main class has Save methods, Add methods, etc. These do conversion and validation and checking for changes in the various components. It does this by comparing the original dataRow bean and the new dataRow bean created by the View class. If there are no errors it calls the TableModel class to update the SQL table. It then regenerates the dataRow bean and returns control to the View class. The dataRow bean has a validation methods for each property. Some of these always return "true", others do validations like range checking and return a true or false based upon the results of the test.  
-TableModel class contains updateTable(), InsertTable() and queryTable methods to access the SQL backend.  
-Layout class - lays out the components being used in the View class. (This is a separate class here to help keep hand tweaking if the application is generated a second, third or 30th time.)  
-Other support classes - a QBE screen, a report system, special components (like a JboundedTextField()).  
 
It is possible at this point the with a rewritten Model class and View class, the rest of the application will be able to run in both environments.  
 

************************
Side note - According to the presentation at the
JUG last week, the accepted standard is that a user
should not wait more than 9 seconds. In the 80's,
using mainframes, the standard was .9 seconds
(sub-second response time). WE HAVE LOST AN ORDER OF
MAGNITUDE. The is one of those "The users have grown
to expect..." BTW, the studies on sub-second response
time showed that users used an application more often
and more effectively when they didn't have to wait for
it.

ISSUES I am looking for.

1.Auto-email to developer/maintainer when certain classes of errors occur.  
2.More on Accessibility  
3.Adding the name of the component to the error list so that the global error messages are linked to the component that generated the error.  
4.Help screens  
5.More on security  
6.Using and Saving User Preferences  
7.Allowing a user to select columns from a table and see a scrolling list of just those columns (in the order the user wants them.)  
8.An easy ad-hoc web based report system.  

REFERENCES

JSF Material
1. Core Java Server Faces - David Geary and Cay Hosrtmann - listed above as "Geary" - best by far.  
2.Java Server Faces Programming - Budi Kurniawan - dated and confused  
3.Java Server Faces - Hans Bergsten - some good ideas - tough to read  
4.J2EE Tutorial at Sun Site - A review for those who already know the material. Not referenced once above  
 
Other Referenced Materials
5.J2EE Design and Development - Rod Johnson - a little dated - excellent coverage  
6.Accessible Web Design - Jim Thatcher et al - a little dated - Very Good reference. Really helps you see how browsers for the blind convert you HTML page into a linear format.  
7.Java Open Source Programming - Joe Walnes et. al. Very good resource.  
8.Java Server Pages Cookbook  
9.Enterprise J2EE Programming on a Budget (more Open Source references)  

There are many other Java books that contributed to JGuiGen - most of them are either basic Java or Swing specific. Books like Java Pitfalls, More Java Pitfalls, Bitter Java, Core JFC, Java Programming on Linux, JDK 1.4 Tutorial, Open Source Development using CVS, etc.