Issue: Creating a screen and layout is a problem for all program designers. There are many programs which let the programmer "drop" and "drag" components around on a screen and to position them wherever they want. This is fine for a "static" screen. But, if things can vary depending upon Internationalization, for example, that method does not always work. There are also programs out there which allow the programmer to define criteria for the screen, store it in another file, such as in XML format, then that information is run through their program, it creates the java files needed to create the screen as desired by the programmer. Thus if a programmer wants to swap an entry, a simple change to the data file will perform the change to the resulting java file. I found this approach to be very appealing, but when trying to find a suitable tool, I found the learning curves were very steep. So, I tried my hand at doing something similar using java classes to store the information.
Discussion: When trying to create java classes to hold the
information about each element on an edit screen it ended up being a much
greater job than I originally thought. As I looked at what
information I needed for each element, I was overwhelmed. Here is a
list of the information items I would need:
- Horizontal location (row of initial placement)
- Vertical location (column of initial placement)
- Horizontal size (width or columns needed)
- Vertical size (height or rows needed)
- Type of input component (JButton, JTextField, etc)
- Arguments to the component constructor (size, etc)
- Type of alternate input component, if used
- If editable/enabled
- Label text, if used
- Post label text, if used
- Help text, if used
- The corresponding Tic (the Tic holding the data)
- The corresponding Record which holds the Tic
Discussion: I realized there was something to be said for storing this information in an external file, then retrieve it when needed. This would allow a change to be done without having to re-compile the program. As part of my Internationalization (I18N) efforts I realized the need for a ResourceBundle, and realized such a class would provide me the needed source for the information for the screen. Unfortunately, I needed some information in a form other than a String. So, some would have to be converted to Integer and such.
Discussion: After literally months, if not years, of trial
and error I realized
that not all of that information needs to be in one place. I could
break down the screen location information, separate from the creation of the
actual field to be placed there. For example, I need some information to
create the entry field, and others to lay it out
on the screen. Here is what I saw:
| Create | Position | ||
| Type of Component | Horizontal Location | ||
| Arguments to Contructor | Vertcal Location | ||
| If editable/enabled | Horizontal width1 | ||
| Label text | Vertical height | ||
| Help text | Width of label side | ||
| Tic | Width of input side | ||
| Tic Record | Gap between components |
1 Possibly inferred from the widths of the two sides plus gap.
2
Discussion: