September 92 - Rapid Prototyping With Handlers in AdLib
Rapid Prototyping With Handlers in AdLib
Nick Nallick
When you hear about the advantages of object-oriented programming, one of the benefits that usually comes up is rapid prototyping. Rapid prototyping is the creation of a trial application that looks like a commercial application without investing much work in programming. This can be very useful when designing the feature set and user interface of a new application.
The addition of behaviors to MacApp allows a new dimension in prototyping. A library of generic behaviors can be created and added to an existing program to provide new functions quickly without additional coding. AdLib carries this capability a step further by providing a general purpose behavior called a Handler. Handlers provide many simple functions in response to various messages within MacApp. Thus, many useful functions can be easily added to a prototype by creating handlers along with the views are created.
How rapid is your prototyping?
One of the reasons for the popularity of HyperCard is the ease with which you go from creating a button to using it. Do you want to add a new function to a card? No problem, just switch to edit mode, create a button, name it, and assign the function to it. Switch back to run mode and you're ready to use the new function. Of course, this glosses over the complexity of the new function itself, but many functions are relatively simple, especially in the prototyping phase of development. For example, when I select this menu item, I want that window to open, or when a particular button is pressed it must signal the application or document.
MacApp has not always been the most convenient prototyping environment. To add the same button as in the HyperCard example, you go to your view editor, create a button, name it, and assign a new class name to it. Not too bad so far, but now you have to go back to MPW, create the new class, override DoEvent(), provide the function, and run through the compile, link, and rez cycle. And, by the way, don't forget to make sure your class doesn't get dead stripped by the linker, or you'll have to run through the build cycle again. If you're trying out a lot of small changes in a prototype, this can get tedious.
The idea behind handlers in AdLib is to move this cycle as far into the view editor as possible. This provides a faster, easier way to perform simple functions.
We work hard so you won't have to.
Handlers are general purpose behaviors that allow objects in an application, such as views, to respond to specific messages by sending different messages to other objects within the application. In other words, in response to a message, such as a mouse command, a view's handler could send some message, such as an event number to the view's document or some other object. Handlers can respond to and send a wide variety of message types, and they provide a number of target objects to send the messages to.
Messages are handled in the same way as you might handle them in a MacApp application by overriding such members as DoEvent() or DoMouseCommand() in your objects. In response to a particular message, a handler performs some action. Actions either send messages, such as events or menu commands, or perform simple functions, such as opening a window or enabling a menu. Most actions are performed on a target object. The target may be the application object, the document, the head of the target chain, or some other object, such as a view specified by its identifier.
All of the handlers for an object are implemented by attaching another object of class THandlerBehavior to it. THandlerBehavior is derived from TBehavior, so handlers can take advantage of the behavior mechanism introduced in MacApp 3.0. Behaviors, if you're not familiar with them already, are objects that can be attached to descendants of TEventHandler in view resources or at run time. Behaviors get a chance to respond to messages from MacApp before the objects they are attached to. A THandlerBehavior object is stored in a view resource with additional data to indicate which messages to respond to, in what ways. A single THandlerBehavior object can provide handlers for any number of messages within an object. The source for the THandlerBehavior class is included with AdLib, to provide for the most effective use in each application.
Since behaviors can be added to any class derived from TEventHandler, including TApplication, handlers can be added to the application object itself. This provides a convenient place to handle menu and other global functions in a prototype. For example, in response to a Setup Menu message, an application's handler can enable all of the appropriate menus. Furthermore, in response to particular menu command messages, it can open the corresponding windows. This, in conjunction with MacApp's default menu command handling, can provide a very lifelike prototype without any high level coding at all.
Handlers are ideal for user interface elements that exist only to send a signal when selected. One increasingly popular construct of this type is the tool bar-a strip at the top of the document window containing small buttons that perform menu commands or other useful functions. Handlers can be attached to these buttons to send the desired menu command or perform other simple functions. Another useful concept is to design objects that respond to custom events through their DoEvent() members. For example, a text document might respond to a "go to the next page" event that could be sent by the handler of an arrow button.
Pay no attention to the man behind the curtain.
Adding handlers to objects in AdLib is a straightforward operation accomplished by point and click functions, without the need for scripting. To invoke the Handlers dialog, select a single view, or to edit the application object, select the AdLib document window, and choose Handlers from the Object menu (the dialog shown below appears).
The Handlers dialog displays a list of all handlers for the object. You can add, remove, or change the priority of handlers in the list. Several handlers can exist for each message type. They will be executed in the same order in which they appear in the list. The right half of the window contains controls to configure a handler. The illustration above shows a single handler for the Menu Command message. The handler will respond to menu command #1000 by sending event #123 to the view with the identifier 'view' in the window with the identifier 'wndw'.
A typical prototype application object will contain several handlers for the Setup Menu message to enable menus, and handlers for each specific Menu Command message to open windows and perform other functions. By handling the Initialize message an application object can display a "splash screen" to occupy the user while the application is starting. Functions in windows and dialogs can be provided by attaching handlers to buttons and other controls within the windows. By clever use of handlers in the application object and controls, in conjunction with the built in menu handling functions in MacApp, you can create a prototype that comes remarkably close to the real thing.
If you add handlers to your application object, you should derive your application object from TBehaviorApp instead of from TApplication directly. This will ensure that all the application's behaviors are loaded during initialization. As it is with THandlerBehavior, the source for TBehaviorApp is included with AdLib.
A recyclable prototype
By editing an application after it has been built, we can change its functions by adding to or changing its handlers. Since we can now add useful functions to an application without rebuilding it, the next logical step is to build a generic application expressly for the purpose of adding functions later. In other words, if we create an empty MacApp "shell" application, we can add resources such as menus and views to the basic shell and create working prototypes without touching MPW. One MacApp application becomes the basis for any number of completely different prototypes. The only trick in this application is to make sure that THandlerBehavior is included. This can be accomplished by including it in the MAMake file and referencing DontDeadStripHandler(). The following is the entire prototype shell program:
void main()
{
TBehaviorApp* application;
InitToolBox();
if (ValidateConfiguration(gConfiguration))
{
InitUMacApp(10); // call MoreMasters 10 times
InitUPrinting();
InitUTEView();
InitUDialog();
InitUGridView();
application = new TBehaviorApp;
application->IBehaviorApp('????', '????');
application->fLaunchWithNewDocument = FALSE;
// if we want this, we can do this with a handler
application->Run();
}
else
StdAlert(phUnsupportedConfiguration);
if (gDeadStripSuppression) // never TRUE
{
extern pascal void DontDeadStripHandler();
DontDeadStripHandler();
}
}
If you have written many MacApp programs you will probably recognize most of this as standard code. We are using TBehaviorApp as our application object to load any application handlers and telling it not to start with a new document, since we don't really have a document class defined. The prototype can pretend to have a document by opening a document window from an Initialize handler in the application object.
Beyond the prototype
Eventually, successful prototypes have to become working applications. It is usually desirable to carry over as much of the prototype as possible to the final application. Today there are a number of prototyping systems available that address this issue by generating source code for a target environment. This has the advantage of working for a number of development environments, but overall it is inferior to a good application framework based approach. The basic problem is customization. As any MacApp programmer can attest to, the default behavior of an element will eventually need modification. If you have to modify the code generated by a prototyping system, it is very difficult to return to the prototyping tools to make a change. You will have to track the changes you have made to the source and put them back each time it changes. On the other hand, changing the characteristics of an element in an object oriented environment is a accomplished by overriding parts of the original. This has little effect on the development tools.
The advantage of using handlers for prototyping then, is that their prototyping capabilities are a side effect of their development capabilities, not the other way around.
We are beginning to see a number of new tools become available that will change the way applications are structured. One significant new capability is dynamic linking-the ability to add new classes and modules to an application while it is running, rather than during the compile and link phase. MacApp now supports an early version of an Apple tool called Dinker (for Dynamic Linker) that provides this ability. With dynamic linking it is possible to create new libraries of objects to build prototypes with more complex characteristics than what most of us are using today. This may blur the line between prototyping and development as prototypes are gradually enhanced to the point where they become the final application.
Conclusion
Handlers provide a powerful mechanism for performing simple functions without creating special classes, and for linking views to other application elements. This eases the requirements on the programmer for creating application prototypes as well as the final applications. By building a MacApp shell application and editing copies of it, you can create any number of useful prototypes without writing any code at all. Furthermore, if you wish, the functions of your prototype can be used directly in your final application with or without change. This is an advantage over prototyping systems that generate source code because changing the generated source makes it very difficult to return to the original editing environment.
Handlers provide a way to add simple functions to an existing application. As dynamic linking becomes more accessible through tools like Dinker, complex functions will also be eligible for addition in this way. This may completely change the way most people develop application software in the future, but for now we can take one step in that direction.
