Levels of Swing Code
Another way to look at what JGuiGen is about is to look at the "levels" of an application that a developer needs to be concerned about.
On the surface it appears that creating a GUI involves two steps 1) finding the right widgets and 2) placing them on a screen. Many of the text books discuss Swing components in these terms.
As you get further into setting up real screens for users in real applications, it becomes apparent that there are levels inside of levels and you can go deeper and deeper into these levels. (Note: In generating this list, I am assuming that Swing components are being backed up by a SQL database.)
Developer Application Issues
1. Display components - including laying out the screen and adding tooltips. Each component is associated with a particular column in the SQL table. Allow different components to be used for a given column. As an example, gender (male/female) can be entered using a text field, radio buttons, a combobox, a spinner or special graphical buttons.
2. Find a row to edit- Set up ways to determine which row in the SQL table should be used to fill the components (e.g. A) specify a row in advance, B) use a JTable to select a row, C) use a Tree to select a row, D) build a SQL query and select a rows, etc.)
3. Obtain data - Get the data and place it into the components - dates and times are especially tricky here.
4. Inherit Components - Visual components should be inherited in a way that changing the characteristics of one parent component changes all instances of that component throughout your application.
5. Immediate Validation - Validate data entry at the point of entry to insure that only properly formatted data is entered into the component - special components and formatted textfields are required here. Improperly formatted data will foul up your business logic, your queries and your reports. In other words it severely reduces the value of the data. This usually involves using several special components (such as the JBoundedTextField that will not let the user enter more characters than a field can handle in the database. SQL updates fail when you try to place 45 characters into a 40 character column.)
6. Screen Level Validation -If the user attempts to save data, make sure required data is present and that inconsistant/incorrect data is detected (e.g. a screen should not indicate the a person's car has four doors when they indicate they do not have a car.)
7. Update the SQL Table - Make sure that the user cannot enter data that will cause the SQL update to fail (e.g. strings that are too long or malformed dates). This needs to include protection against corrupting the data through accidental bad data or SQL injection attacks.
8. Multi-user conflicts - During the save, make sure that you are not writing over data that another user just entered (multi-user conflicts).
9. Default Values - When adding a new row make sure that each component starts with the proper default value (make sure the data does not come from the previously edited row and if the database has a default value for a column, the associated component should start with that value.)
10. Primary Key Value - When adding a new row make sure you can tell what primaryKey was just created. This is needed for creating tests and for saving data into several tables where the generated ID for the first table (e.g. customer number) should be used as part of the key for the other tables (e.g. address table).
11. Log Activity - Make sure that the developer has a way to see errors (logging). (There are those who say to minimze what the user can see since additional data helps attackers. I have decided to help the developers by providing the data. This decision is subject to change.)
12. Log Program Version - Make sure the developer has a way to tell what version of a program the user is running when looking at logs.
13. Multiple Distribution Environments - Make sure the components work when running in classes, jars, wars, Java Web Start, etc. They do not by default.
14. Multiple Platforms - Make sure the components work in different opererating systems. Accessing local files is espeically tricky here.
15. Internationalized - I18N - Make all of the display text, hotkeys, date/currency formats variable so that the application can run in different Locales properly.
16. Accessible - A11Y - Set up components so that they are keyboard accessible, designed to aid the visually handicapped and are set up behind the scene to handle readers for the blind.
17. Look and Feel - Make sure the system can change look and feel, both to handle different system defaults and user preferences.
18. Fonts - Allow the user or company to change the font used by the application to fit their needs. This includes making sure that fonts are available (ship them with your application), using anti-aliased fonts and changing font sizes.
19. Colors - Allow the user or company to change the color scheme used by the application to fit their standards or needs. Users with special needs (such as color blindness or poor eyesight) also need to be able to change the color scheme.
20. Undo - the system should have some ability to undo changes. - not available yet.
21. Drag and Drop - Components should handle drag and drop where users expect it.
22. Resizable - Allow users to resize your application to fit their tastes, screen size and needs.
23. Size - Make sure the application runs well on systems using different screen resolutions.
24. Preferences - Save user preferences for screen size, font, shape of Jtables, etc.
25. JUnit - Build test cases to test that the component is doing what it is supposed to do during add, edit, view and delete.
26. Document - Write systems that are documented (the tables in the database, the columns in the table, fields in the code and methods in the code.)
27. Style - Write code that meets a set of style standards.
28. Release memory - Write code that releases memory when it is done with it.
29. Encapsulate - Code should encapsulated so that changes that are virtually certain to happen can be taken care of in one place and will not affect the rest of the code (e.g. changing SQL back end databases).
30. Security - Code should have some level of security built in. Passwords to data bases should not be easily obtained from your application. Selected users should have limited rights to use parts of the program.
31. Encryption - Encrypted data fields should be available and encrypted access to the backend database should be supported. - not availabe yet - almost.
32. SQL Backends - Company needs change and the backend databases change. Make sure the application is setup to handle different SQL Backend databases with a minimum of fuss and bother.
32. LDAP - Access to the application should use LDAP where appropriate.
33. MVC - Try as much as possible to keep the Model, the View and the Controller sections of your code separated.
34. BLOB - The system should handle large binary objects (images, audio, etc.) - not available yet.
35. Transactions - Where appropriate make sure all updates happen or none happen. Do not allow partial updates where one table is updated and another table that should have corresponding entries is not updated.
36. Help - Integrate Help Systems and on-line user helps with your applications.
37. JavaBeans - Java developers expect data to be stored in JavaBean. JGuiGen uses two beans - one holds the data before the user edits and the other holds the data after the user edits.
38. Reports - Users want reports - make them available to your application.
39. Drag & Drop - Dragging images, URLS, and text is expected in some places.
40. Visual Components that Remember - Web users expect some components to ofter auto-completion, lists of previously entered information.
41, Status Bar - Many applications have and needs a status bar at the bottom of the screen. - not available yet.
42. Text Search - Users expect searches such as those that the Lucerne Libaries make available to Java.
43. Start/Open - Windows has Start.exe and Mac's have Open as small utility programs that open other programs in the operating system. Access to these is required.
44. Single Launch - Some applications should only be lauched once per machine. There are ways to make this happen and should be available.
45. Animated Cursors - In some places an animated cursor is ideal.
46. Self Running Demos - Demos that a user can start are very good training tools.
47. Interface other Applications - You application should be able to call up other applications as needed and share data with standard applications such as Excel.
48. Checking for system file names - Windows boxes accept file names that are incorrectly cased. JARs and *nix systems do NOT.
49. Statistics - Generic database applications should have some way for users to summarize data they are looking at. JGuiGen allows them to obtain a frequency count on any column - with or with filtering the data first. For numeric variables you also can obtain a mean. It is possible to mark certain values as "missing" and get the frequency count percentages and means based on the non-missing data. This data can be exported to an Excel file or the clipboard for export to other applications.
50. SQL Injection - querying, inserting, deleting and update data in the SQL table should be as safe as possible against SQL Injection attacks.
51. Data Replication - how do you synchronize data between two or more sites.
Quality of User Interface
1. Avoid Data Loss - If the user edits the component and does anything that will lose that edit - notify the user.
2. Immediate Validation - Validate data entry at the point of data entry (in the component).
3. Validate on Save - Some data can't be validated until the user has made all of their entries. Handle this gracefully.
4. Error Notification - Be sure to EMPHATICALLY notify the user if an insert or update does fail.
5. Error Reporting - Make sure the user has a way to report errors.
6. Keyboard Accessible - Make the components keyboard accessible - especially tricky when combined with the Internationalization requirement. Hot keys that work in one language may not be visible in another language. Making the popup menu and the JTable keyboard accesible requires special attention.
7. Focus Order - Make sure the focus order is appropriate for your data entry screen. (Tabbing should move from one component to the next logically.) (JTextArea and JTable are non-standard since by default a TAB does not exit the component.)
8. Back-out - Make sure that the user has a way to back out of an action if they have initiated it in error.
9. Current Values - If using a pop-up component to assist with data entry make sure the user can tell what data is already in the component and has a way to revert to that value.
10. Undo - Allow user to undo changes. (JGuiGen keeps a log that administrators can use to undo changes. It does not currently have an active Undo feature.)
11. Help - Make sure that there is a Help Screen available to help the user understand the data.
12. Print - Make sure that there is a way to print screens.
13. Error Notification - Make sure that the user has a way to see errors (perhaps a console).
14. Look and Feel - Default to the native system look and feel - let the user override this.
15. Preferencees - Save user preferences for screen placement, window sizes, look and feel etc.
16. Visual Clues - Make sure that components that require special actions are highlighted in some manner. (e.g. REQUIRED fields, pop-up warning and error messages when things are wrong.)
17. Application Busy Clues - Make sure that long running actions give the user an indicating that they are running (cursor shape, progress bar.)
18. Action Availability - Make sure that components indicate their availability status (buttons, should show up, pressed, unavailable, under the mouse; textfields should show that they are editable or not editable.)
19. I18N - Make the components internationalized (both language and national standards for dates, numbers, time, money, help screens, icons, etc.)
20. A11Y - Make the component accessible to assistive technologies (screen readers, alternate data entry devices, etc.)
21. Usability - Take care of the "usual" things like intuitiveness, consistency, usability.
22. Change Notification - Notify users when they are using an updated version of the program. Tell them what has changed.
23. Reports - The system should have a way to generate simple reports.
24. Cut and Paste - users expect to be able to cut and paste. Copying items from a Jtable takes special attention.
What the heck - why don't you generate the code in order to be sure that it takes care of all of these levels properly. JGuiGen handles all of these issues (except Transactions which are N/A and immediate Undo which is questionable here.)