Issue: The issue is how to implement the address fields on the screen. The Address object has two String fields which are for address lines one and two. It also has a PostalCode object. The PostalCode object has a code String, which is a look up for a City and State pair, which are also String fields. In theory, the code will uniquely match a City, State pair, as the U.S. Zip codes tend to do. Thus a fictional U.S. address might look like this: 123 Main Street, Apt A, Anytown, ZZ 01234. In this case, the 123 Main Street portion would be in address line one, Apt A could be in address line two and the reminder is the PostalCode of Anytown as the City, ZZ as the State, and 01234 as the code.
The reason for separating the PostalCode should be obvious. In any league there may be say 100 bowlers, yet only 10 to 20 postal codes. This avoids having the user enter in the city and state information each time, and prevents errors. The address is separated from the postal code because there may be many different addresses in any postal code. But, there are many times when a family has several members as bowlers, in which case there should be a way to enter that address once and select it again for the other family members. There is also the possibility that the same address may apply to two different postal codes. That is, 123 Main Street, Apt A may be the address for two different bowlers but who live in different Cities and thus have different postal codes. This all presents an issue when trying to implement a GUI screen for the user to select, edit, and add new Address objects.
Discussion: My first thought was to use a JComboBox with the edit function enabled. That is, the user could drop the list of addresses down and select an existing address, or enter a new address into the text box, if needed. The first problem is the PostalCode object, and how to implement that. It too could be a JComboBox with editing enabled. But, each of these are more than one field, so how do you implement that with one or even two JComboBoxes? I thought of having one JComboBox with a separate textfield(s) for the secondary fields, but that really doesn't work well. Catching a new entry into a JComboBox is not easy, and I couldn't make it work in a way that seems logical to a user.
Keeping the process easy for the user is a primary concern. After all, the the whole reason for creating the Address and PostalCode objects is to make things easier for the user. If I make it difficult to understand or use, then I've failed.
Conclusion: I decided it had to be done with several
GUI elements and a series of cascading dialog boxes. I envision the
subsection of the Bowler screen to look like this. The "New"
and "Remove" buttons are separate from the ones on the Bowler
screen on the left side. These buttons apply strictly to the address
section. The only enabled component, besides the action buttons, is
the combobox for Address 1. The others are disabled because the
intent is for the user to select an existing address. When the
user selects an address in the combobox, then the information for the
other fields is updated to reflect their matching values.
If the user clicks the "Remove" button, then a confirmation dialog
should appear, and if confirmed, the address will be removed from the Address
store, but not the Postal Code. Clicking the "New" button
will bring up a dialog for a new address to be entered. It might
look like this:
|
In this dialog the user can enter a new address and select a postal code to
go with it. If the user needs to enter a new postal code, then
the "New Code" button is clicked to bring up another dialog to
enter a new postal code. It might look like this:
|
When the OK button is pushed, the code should be checked against the existing list of codes to see if it is a duplicate. If it is a duplicate, then the user would be prompted with a confirmation dialog stating that the code already exists and does the user want to update it with the information just entered. If yes, then that's what happens. Unless the cancel button is pressed, the newly entered code is then brought back to the New Address dialog, and added to the Address Store. There should probably be some way for the user to remove a postal code from the store.
While this seems like a lot of screens to go through, I think in the long run it will save time and mistakes, once the codes and addresses are entered.
June 12, 2012