Many application domains naturally possess an unbounded set of desired features. A signals processing application, for example, needs an unlimited number of filters. A symbolic math package, an unlimited number of mathematical operators. A graphics package, an unlimited number of sketching tools.
Of course, no real application can present an unlimited number of anything to any given user. However, the market as a whole does appear to want an unlimited number of features. What's a developer to do?
Some developers have met this challenge by building in a capability to extend their applications. Using this feature, end users can configure a graphics package, for example, with a set of sketching tools tailored to their needs, or even modify the set of available sketching tools while the application is running.
This enables users to get the maximum use of limited RAM and disk space. Instead of running in a six megabyte MultiFinder partition, for example, an extensible application, with only the needed tools loaded, could run in, say, four megabytes. In fact, one of the best selling MacApp applications, Adobe PhotoShop, uses an extensibility approach with their plug-ins to add new image manipulation algorithms and data access procedures to the application.
Up until now, MacApp has provided no support to those wanting to add extensibility to an application. To make matters worse, the most natural way to add functionality to a MacApp application-by adding new classes to the running application- was something no one had ever done. Some people even thought this was impossible to do on the Mac.
Dinker, the results of recent work by Apple's Advanced Technology Group, adds exactly this capability to MacApp. This article describes what Dinker does and how you can use it in your application. Other articles planned for later issues of FrameWorks will cover Dinker internals and case studies of adding Dinker-based extensibility to commercial MacApp applications.
Dinker is included on the next Essentials, Tools, and Objects CD (ETO 6) as a currently unsupported MacApp experiment. It will be demonstrated at the Orlando '92 MADA Conference in February.
The basic run-time architecture of a Dinker application is shown in Figure 1, and then in greater detail in Figure 2 (next page). Dinker will set up entry and exit points in the base and all extensions, and will ensure that the proper global environment (A5 worlds, resource chains, etc.) is established upon crossing the boundaries between the base and the extensions, or between extensions.
Building an application that can be extended at run time via the Dinker is easy. Tell the Dinker version of MABuild to build the application to make use of Dinker. Such an application is called a "base." Then, use MABuild to build each dynamically linkable extension for the application (called an "extension" or a "component"). The total Dinker package used by a MacApp programmer-Dinker itself, the Dinker-aware modified version of MacApp (either a modified version of MacApp 2.0.1, or a modified version of MacApp 3.0ß3), the Dinker-aware version of MABuild, etc.-will cause the entry and exit points to be constructed for the base and for all extensions, and will resolve, at run-time, the invocations of these references. (See future FrameWorks articles for an explanation of the Dinker's inner details.)
A note on terminology-Dinker is a dynamic linker. It lets you "dink in" a new class into a running application. Among dynamic linkers, Dinker is unique in that it enables the dynamic linking of new classes into an object oriented application, like a MacApp application. For a time, the term "oinking" was used to describe this dynamic linking, but this term has fallen into disfavor with the Dinker implementors. A later, supported version of Dinker may have a slick, marketing-approved, copyright-obtained legal name. We hope that all savvy MacApp developers will continue to call it "Dinker" in perpetuity.
Extensibility lets you achieve these opposing goals. Users can pick which tools to load in the default case (by, for example, placing these in a distinguished folder), yet still have easy access to the tool needed on special occasions. In this way, Dinker lets users manage the resources needed to run your application much like Fifth Generation System's Suitcase™ II lets the user manage fonts, desk accessories, FKEYs, and sounds.
In addition, for those developers who wish to encourage a third-party market surrounding their applications, Dinker provides a way for other MacApp developers to leverage off of your application by developing extensions for it. These third parties will need the entry and exit vector files the Dinker-modified version of MABuild prepares for the application. These could be part of a developer's kit for your application. Developers of extensions do not need access to the source code of the base.
One interesting technique uses a MacApp method that you probably haven't used before: ForAllSubClassesDo in TObject. I used this technique to add an indeterminate number of dinked-in views to a window. It just happened to be the case that while each of these new subviews was a instance of a different class, all the classes were subclasses of a class unique to my application (TBannerView). The code looks like this:
PROCEDURE TBannerDocument.DoMakeViews(…);
OVERRIDE;
VAR theWindow: TWindow;
theFirstView: TBannerView;
currentLoc: VPoint;
aView: TBannerView;
PROCEDURE AddAView(theClass: ObjClassID);
BEGIN
currentLoc.v := currentLoc.v + 135;
aView := TBannerView(NewObjectByClassID(theClass));
FailNIL(aView );
aView.IBannerView(…); { this will add it as subView }
END;
BEGIN
SetVPt(currentLoc, 0, 0);
{ Prime the pump by setting up the window
with the first view }
theWindow := NewTemplateWindow(2222, SELF);
FailNIL(theWindow);
theFirstView := TBannerView(theWindow.FindSubView('MNBN'));
{ Now add the rest of the views }
theFirstView.ForAllSubClassesDo(AddAView)
END;
You could use the same technique to build a palette (when all the new tools to be configured into the palette are subclasses of something like TAbstractTool), or a hierarchical menu.
PROCEDURE TShapeApplication.DoMenuCommand(
aCommandNumber: CommandNumber); OVERRIDE;
VAR
anExtensionFile: TList;
aDomain: TDomain;
r: Rect;
shape: TShape;
toolsView: TToolsPalette;
toolsMenu: TToolsMenu;
PROCEDURE DoToItemInExtensionList(item: TObject);
BEGIN
aDomain := GetExtension ( TFile (item) );
IF longint(aDomain) <> 0 THEN BEGIN
{ Define the prototype shape this component }
SetRect(r, 9, 49, 31, 71 );
OffSetRect(r, 0, 40 * ( gShapesInPalette ) );
shape := TShape ( Instantiate( aDomain ) );
FailNil(shape);
gShapesInPalette := gShapesInPalette + 1;
shape.IShapeExtension(r, gShapesInPalette );
gShapesArray[gShapesInPalette] := shape;
END;
END;
PROCEDURE ForceWindowRedraw ( aWindow: TWindow );
BEGIN
aWindow.ForceRedraw;
END;
BEGIN
CASE aCommandNumber OF
...
cGetComponent:
BEGIN
IF ChooseDocument( cGetComponent, anExtensionFile )
THEN BEGIN
anExtensionFile.Each( DoToItemInExtensionList );
anExtensionFile.Free;
{ Now add the new shape to the palette }
toolsMenu := TToolsMenu(gToolsMenu);
IF longint(toolsMenu) <> 0 THEN
toolsMenu.AddTool;
... { Add to Tear offs, etc. here }
ForAllWindowsDo( ForceWindowRedraw );
END;
OTHERWISE
INHERITED DoMenuCommand(aCommandNumber);
END; {Case}
END;
What is "significant?" Addition or removal of classes, addition or removal of methods, addition or removal of any entities that the linker needs to know about (for example, invocation of a new Toolbox routine, or moving something from the private interface to the public interface) are prime examples. "Insignificant," from a Dinker point of view, are changes to the implementations of methods or functions that don't add or remove Toolbox calls.
Unfortunately, the situation is not so rosy with respect to a MacApp 3.0ß3 application, or a non-MacApp application. Yes, you can use Dinker without using MacApp. However, it isn't as easy or as convenient, mostly because we planned the first Dinker release to concentrate on the use of Dinker by a MacApp programmer.
The new MABuild, for example, handles the complexity of building the entry and exit vector segments without any work by the MacApp programmer. There are currently no such automated build facilities for the non-MacApp developer. There isn't much debugging support in either SourceBug or SADE® for dynamically linked extensions. Basically, neither of these tools yet know how to read the multiple SYM files associated with the base and all of its currently dinked in extensions, nor do they know to reassess a class hierarchy that has been modified dynamically by Dinker. However, that doesn't mean these debugging tools are useless with a Dinker application. You can use SourceBug with Dinker applications, but with these limitations:
I hope that these limitations will be removed in the future.
Finally, a goal of Dinker was to require only minimal-and preferably pro forma-changes to a class to change it from being a statically linked piece of functionality to one that could be dynamically linked into the application. We believe this goal has been met. Thus, one possible debugging strategy is to develop and debug your application as a monolithic, statically linked application, and then when it is "bug free," to peel off various pieces of functionality into dynamically linked extensions. (Okay, okay. We know that this is kind of lame, and that your testing manager just had a heart attack even considering this approach. But it's better than nothing, and this is only the early experimental release.)
While it is implemented according to the same architecture as Finder Extensions, Dinker adds significant new dynamic linking functionality to Finder Extensions and thus an extended period of testing is needed. The Dinker work was done by Apple's Advanced Technology Group and is being shared with third-party developers for experimentation and evaluation. If you find dynamic linking to be a useful feature, then it may be supported and extended in future MacApp and MPW releases. Let us know by sending an AppleLink message to the Dinker Product Manager, Tom Chavez (TOM.CHAVEZ).
