A user interface builder allows programmers to draw and test an interface interactively without writing code. In many cases, such tools can have an extremely beneficial effect on a programmers' productivity during the early development and design stages. Most such tools allow a programmer to create an application's interface and then go immediately to a "play" mode, in which the interface responds to user input. Users can press buttons, type in text and so on. By reducing the time a programmer spends compiling and debugging, a builder can greatly reduce the amount of time required to create a first prototype of a user interface. Using a builder allows a programmer to show a realistic prototype of an interface to potential users before committing the design to code. Most such tools can produce code that corresponds to the interactively- developed interface. Since generated code will normally be free of syntax errors, programmers can typically have a running program with a complete user interface after the first compilation.
Unfortunately, currently available builders have several serious deficiencies that have not been adequately addressed. One of the most serious problems involves support for future evolution of generated code. Once a programmer has generated code for a builder- produced interface, the code cannot be modified if the builder is to be used to alter the interface at a later time. If the code is modified, the builder is no longer useful. But few builders produce code that is complete. Programmers always need to modify the code to connect various modules, make enhancements, and so on. Most builders have tried to address this problem in various ways, but few have been completely successful. Another serious problem involves the code structure or application architecture supported by current builder-generated code. Most builders support C or UIL code generation. The C code produced by most builders tends to be monolithic - all the code required to generate the entire user interface is typically placed in a single function, which is seldom a desirable architecture for real applications.
The component-based approach supported by the ViewKit framework is well-suited to an interactive user interface builder, and leads to solutions to several of these problems. First, a builder can be used to create individual user interface components rather than an entire application. A builder can allow ViewKit components to be created quickly and easily. Because these components tend to be small, functionally cohesive units, the problem of an architecture based on monolithic code segments is avoided. When used in this manner, a builder can actually encourage an object-oriented architecture based on collections of components.
Object-oriented technology also provides one solution to the problem of modifying generated code. All classes created by a builder can be treated as abstract base classes, which are never modified. Programmers, of course inevitably need to write some code to connect such classes to the rest of an application. When using the object-oriented approach described here, application-specific code can be added easily by creating subclasses of the generated class and modifying only the derived class. So long as no changes are made to the base class generated by the builder, it can be reloaded into the builder at any time and modified as needed. Of course, changes made to the base class must be carefully controlled to avoid removing any elements on which derived classes depend.
___________________________________________________________________