Dialog Box

By Matt Neuburg, letters@mactech.com

Hello Java, Good-bye OLE and OpenDoc

Sometimes, when we are lucky, reality sneaks up and screams “Hello!” when we most need it.

Thinking about how to write extensible applications in Java, I was listing requirements, procedures, and issues for communication and control between the main application and the extensions. What is the minimum core of OLE and OpenDoc? Does it really have to be as complicated as OpenDoc?

Then reality suddenly screamed, “Hello! Isn’t a Java-enabled browser one of the most extensible applications we have ever seen? How is that done?”

A browser can load and run essentially “anonymous” applets, of any complexity, that can do just about anything - even bring up windows and work with files (when permitted). What more could we want?

Well, for extensible applications in general, we could want custom menus, closer integration into the application, and more access to the application’s data. As it happens, all this is possible - right now - with Java; the implementation of a browser shows us how.

We extend the Applet class to make our own applets. The Applet class establishes a few “entry points” (methods) through which a browser can tell the applet to initialize itself, run, update, and so on. The applet can do whatever else you want in addition to these few responsibilities.

For its part, the browser must implement the AppletContext interface, which dictates the services the browser must provide to any applet. If both sides fulfill these contracts, the browser can use Java’s ClassLoader to load an applet from a local or remote file, place it into the browser’s own window, and run it.

To implement our own extensible applications, we don’t have to use applets (although we certainly can); we just need to set up the kind of contracts established by the Applet class and the AppletContext interface. Perhaps we will include ways to share menus and application data; the particular methods are our call (so to speak).

Now think of the silliness of first implementing a Java-enabled OpenDoc part, then rewriting applications to accept OpenDoc parts! Or just rewriting for OpenDoc in general. Why not rewrite the applications in Java, and get straight to the point?

“Hello!” Which is the actually existing revolution - Java, or OLE/OpenDoc?

It’s time to tell OLE and OpenDoc (and VBXs, OCXs, XFCNs, MOBJs, XTNDs, and so on) “Good-bye!”

“Uncle Dave” Moffat

Mac Web Tools Redux

In the May 1996 Dialogue Box, Ziya Oz writes:

“At the last Macworld Expo in Boston, I asked myself: If Ceneca was not formed by ex-Taligent people, would they have developed Page/SiteMill for the Mac OS first? Would they even have developed for the Mac at all? My answers are: No and No again.”

His conclusions are erroneous. Ceneca initially planned to write PageMill for Windows. However, when they spoke to Web authors at several companies, they found out that Macintosh was the dominant platform for creating Web content. Ceneca therefore changed their strategy and developed a Mac version instead. (I learned this from Robert Seidl of Ceneca/Adobe at the WWDC.)

The majority of Web content is created on Macs. Macintosh is also the second most popular Web server, after UNIX. A developer writing content tools would be wise to publish a Mac version of his product.

Terry Morse

Language Wars Redux

Many Mac OS programmers still code in Pascal - and that’s OK. But they (and MacTech Magazine, too) should give another language a try. No, I’m not talking about C++ or Java; I’m talking about Oberon-2 (Pascal’s grandchild, so to speak). Interested? Then read on.

MacOberon, Oberon System 3, and Oberon/F generate 68K code. PowerOberon generates PowerPC code, but has no linker yet. Or you can use MPW. The URLs are:

ftp://ftp.inf.ethz.ch/pub/Oberon/

ftp://oberon.ssw.uni-linz.ac.at/pub/Oberon/PowerMac/

http://frodo.informatik.uni-ulm.de/projekte/MPWOberon/

As a CodeWarrior, I hope that Metrowerks will integrate this fantastic language into their IDE. But, till then, I’m perfectly happy with C++ and PowerPlant.

By the way, to “serious” Oberon users I recommend Programming in Oberon and Object-oriented Programming in Oberon-2 (both from Addison-Wesley).

Paul E. Sevinc

[Our paucity of articles written in Oberon is not due to any want of trying. In fact, we have a review of Oberon/F in the works; watch for it in a future issue. As always, the best way to ensure coverage of your favorite area of expertise is to participate by writing us an article yourself - man]