ex tend \ik-stend' \ v: to make longer, wider, or braoder
As a programmer, you know a program is never complete. It is a rare occasion when you can walk away from an app saying, "That's it! I can add nothing else!" It is a very rare occasion indeed. Well, the software in this tutorial is no different. There is always room for improvement. In any case, this chapter will cover a few areas where you might be able to extend the Java Intranet Framework to get even more use from it. Some of these ideas came to me during the writing of this tutorial, others I purposely left out for you, the reader/programmer, to create yourself. What fun is it if I do everything? Take a look back at each of the separate packages and go over some of the ideas for extending those classes.
The jif.util package contains several utility classes. They are created for demonstration purposes and for use in the apps in this tutorial. Of all those classes, only the FileDate and ConfigProperties classes have room for extension. The timers can be extended; however, you would be pushing the functionality beyond a simple timer. They should be used within classes rather than be subclassed. However, it is always the case that classes developed by one person are used by another in a manner that the author never thought of.
Although this class is quite useful, it does do one specific thing. If it finds a property called jdbc.drivers in your property table, it adds it to the system property table. This mechanism is very specific. It only looks for that single property. An excellent enhancement to the ConfigProperties class would be to make this mechanism more configurable. This means that you would be able to tell the class which properties would be merged with the system property table. The class could then keep an array of these properties and deal with them at runtime. Another thing that you could do is make the ConfigProperties class merge all of the private properties with the system property table. Then the overridden getProperty() method could call the System.getProperty() method directly.
This class went through many changes over the course of writing this tutorial. It went from having only a single purpose to having many. Although not perfect, this final version of FileDate is quite versatile. One idea for extending this class is to create a more user-friendly date formatter, perhaps one that is not tied to constants. This formatter would possibly accept as input a string representing the format that you would like your date returned. This format string could use simple MM-DD-YY strings.
The logging classes presented in this tutorial are quite simple. They write a static format out to the log. These classes could easily be rearranged and extended to provide a much more robust logging system. One example is to abstract the formatting of the log entry out to a separate class. Make it a stream class like some of the Java classes. This class would be the only one that knows how to format log entries. You could then create output classes that plug in to the formatter class. This is probably a far more object-oriented approach than the one taken in this tutorial. If you did do this, you could then make the formatter configurable as well. Instead of always putting out the same information, let the consumer or user of the object specify in what fields, and in what order, they are written to the log. This would give you a robust and configurable logging system.
The classes in this package represent database communications. These classes are very useful. However, with a little work, you might not have to code much anymore. The next logical step for the classes in this package is for them to automatically query the database. This query would retrieve the table structures from the database. The classes could then dynamically construct themselves to mimic each table. This is pretty extreme, but definitely possible. Another, more likely extension, is to create a class that represents a window into a table. This window would allow the programmer to specify the SQL statement that loads data. This information is then available to be put through a user interface. The class could then maintain a cursor, or pointer, as to which record is current, and automatically scroll through the data using the same user interface. Then, once changes have been made, all the SQL would be generated to update all the data changes that were made.
Being the largest package in this tutorial, the jif.awt class has many areas where it can be extended. Take a look at some of them:
Currently, the JifPanel is static in size. One extension could be to make it more dynamic and let it grow with its surroundings. If a resized window contains a JifPanel, the JifPanel might want to grow with the window. Getting this to work with hard-coded sizes, though, might present a coding challenge. Also, the JifPanel currently draws its three-dimensional frames in the old Microsoft Windows v3.x style. Another extension could be to upgrade to the newer Microsoft Windows 95/NT look. This 3-D look is cleaner and more modern-looking. It is used in the JifTabPanel.
The JifTabPanel is one of the more complex classes in the jif.awt package. It consists of two subclasses that do its bidding, but it is far from perfect. The following are some ideas for enhancing the JifTabPanel. Currently there is no way to disable a tab. You could add the functionality to enable and disable tabs in the panel, but this would restrict users from looking at data on that pane if it wasn't visible. The JifTabPanel has two operating modes. In the first mode, the entire width of the bounding rectangle is used for tab space. This means that if there are two tabs, the width of each tab is relative to the width of the parent container. In the second mode, the tab width is relative to the width of the text string that is displayed by the tab. This is the default mode. However, if more tabs exist than can be shown, they are cut off. An excellent enhancement to this class would be one that places a set of buttons at the end of the tab panel to move backwards and forwards. This would avoid the loss of tabs and scroll the entire tab portion so the user can see what lies behind. This effect can be seen in several Microsoft Windows products today. Another enhancement would be to let the programmer/user specify the font. Currently the fonts are hard-coded to be dialog-style fonts. Perhaps someone would like other fonts. This class is far from perfect, but it can be extended to be an awesome class.
This class could be extended to allow the programmer/user to select the font and style of the border. This information is currently hard-coded in the StatusBar class.
There are only a handful of Java components that have been enhanced to generate SQL. This is an obvious area of extension. One good choice for extending in this regard is the Choice class. It could be made to generate SQL for you. In addition, you could create an extension that would act like a code table. It would display descriptive text while returning a code from the selection. This is a very useful feature.
Although complex, and the user of many classes, the Jiflet class really offers no areas for extension. There is one possible enhancement that could be made. You might want to enhance the Jiflet class to descend from a Thread. This would make the main jiflet run as a thread. You could then stop and start it at will. It might come in handy sometime. You also might explore the possibility of extending the jiflet to work as an applet instead of as an app.
The apps in this tutorial, though useful, are not all perfect. This section will detail some areas where they could be spruced up by you. Currently, all the apps require the DBConnector to be created for them. You could enhance the core Jiflet class to build a DBConnector based on a configuration property. This would allow you to change databases on-the-fly with a configuration file change, instead of a source code change. This would eliminate the need for recompilation as well. In addition, each of the apps require you to manually connect with the database. This could be made automatic at startup. Then the user would not be required to perform this action. Take a look at some specific enhancements.
This app can be expanded to do much more. Currently, it only manages the lowest common denominator. Many retirement plans today allow you to change your investments in different areas. This is not represented at all by your maintenance program. This would, however, make an awesome enhancement. Allow the user to choose the fund and percentage of his money that would go into that fund. You would need a separate table to hold the new information, but the usefulness of the app would jump tenfold. This information could then be sent electronically to the benefits administrator, or even directly to the benefits company.
One of the features of this program was left for the reader to complete: the delete function. You currently cannot remove a previously scheduled conference room. This is a good place to jump in and get your feet wet. In addition, there is no program for creating conference rooms. They must be entered through a database manipulation tool, or a program needs to be created. This is a great small jiflet. You can model it after the Employee Files app.
This app lets you enter News and Announcements, but there is no way to delete them. A likely addition to this program would let you delete news items that are of a certain age, or perhaps not show them. Also, there is no refresh in this app. A good extension would be to program in an automatic timed refresh like the one in the Online In/Out Board.
This chapter recapped some of the areas where the Java Intranet Framework could be enhanced to provide more flexibility and functionality. I covered each package individually and noted areas of improvement. I also looked at areas of improvement in the sample apps. This brings you to the end of the tutorial. I hope you have enjoyed reading it. I also hope you have learned how you can use Java to develop some killer intranet apps for your company or customers. Please feel free to e-mail me your comments, suggestions, gripes, and so on. My e-mail address is listed in the front of the tutorial. I would love to hear what you think about Java and intranets.