Omnis Studio 1.1
Saturday 14th February, 1998
In contrast with, and perhaps because of, its success in design and education, the Mac has not generally been taken seriously as a heavyweight business tool. The arrival of Omnis Studio 1.1, an incredibly powerful piece of business development software, could just change all that. The program, a turbo-charged version of the relational database, Omnis7, is an object-based, cross-platform multi-user programming environment. And even that’s an understatement. It’s not just cross-platform, it’s cross-everything: it runs on Mac OS, all flavours of Windows and soon, apparently, Unix as well. It’s cross-database: it will act as a front end to Informix, Oracle, Sybase and Microsoft SQL Server, and any other ODBC database you care to mention. You can integrate ActiveX and JavaBeans object technologies. And with its free Web enablement software you can provide full HTTP, email, FTP and TCP services. All this is controlled and coded in a single programming language, Omnis Script.
Each element of your application is built using a collection of Omnis Studio objects and external components (JavaBeans and ActiveX components, for example). Each Omnis object has a set of ‘properties’ which can be examined and changed. You can communicate with these objects by sending them ‘messages’, which they respond to by performing actions using pieces of code called ‘methods’. Omnis Studio objects also include a separate group of properties called ‘variables’ for storing local data.
Omnis objects have all the characteristics C++ or other object programmers would expect, including inheritance and re-use. Inheritance means you can create objects that inherit their behaviour from other objects. So, for example, if you have a class that stores information about a person, you can create another class, say a traffic warden, based on the person object, but with additional properties and methods specific to a traffic warden. This standard object-based approach means you don’t have to re-invent the wheel for every new object, making it easier and quicker to write new applications based on objects you’ve already written.
Even Omnis7 3.0 users will find some of Omnis Studio’s features unfamiliar. For example, Library files are now objects in their own right. They continue to store all the interface and data elements used to build an application, and contain 11 different internal categories. Window, Menu and Toolbar classes are for creating the user interface elements, and Report and Search classes for managing the way in which data is displayed and selected. These classes replace the ‘formats’ in Omnis7. In some cases it’s a straight replacement; in others, for example the Window objects, the Omnis7 concept has been enhanced.
Class act Omnis Studio applications are based on a front-end application (the user interface) interacting with the back-end database (a company database server such as Oracle, Sybase, Informix or an ODBC-compliant database). To manage this process there are a couple of new classes: Schema and Table classes help describe and control external SQL databases and Omnis Cache, the built-in Omnis database engine.
Schema classes, including the database name, the column names and data types, and the indexing information, describe a table or view in a database . For database users who have been suckled on FileMaker and who have managed to avoid the AppleScript Database Object Model, a ‘column’ in a database is roughly equivalent to a field definition in FileMaker and a ‘row’ in a database is equivalent to an individual record.
Table classes describe the interface to a database defined by a Schema class. Table classes don’t store any data themselves, but instead contain the various methods for retrieving and storing data in the external database.
Also in the armoury are Code and File objects. File objects are similar to Omnis7 file formats, defining a sort of field template for storing records in an Omnis Studio data file. Code classes enable you to share methods between objects of different classes - for example, a menu and a toolbar - so you don’t have to maintain the same piece of code in two different places. There are also new Object classes, which enable you to create your own kinds of data objects.
Task master Finally, there’s the Task class. To understand what a task is and what it does, you have to know how the Omnis Studio programming model works. The program follows a version of the ‘event’ programming model, as used by HyperCard. When a user performs an action, it’s recorded as an event. Information about this event is passed to each object the user interacts with in turn: click on a button or a field and a mouse click event is sent to the object. If that object has code for handling that event, then it deals with it; if not, then it passes it up the hierarchy, perhaps to the dialog box containing the field or button.
Omnis Studio’s classes act as templates for objects - think of them or moulds. To build an object, you need to create an individual instance of a class. A Task is a runtime container for all your other objects. When you start an application, Omnis Studio creates the first Startup Task and from there you can create further Tasks. Every object you build will belong to a Task, and each Task acts to put your objects in context. When a Task is brought to the front, all its objects are brought to the front, too - so you can link menus, windows, and toolbars to the same Task and have them all appear whenever that particular Task is called on. Another way to think about it is in terms of a family tree - every object belongs to a parent object.
Omnis Studio implements this idea using something called Notation. Notation enables you to specify an object in terms of its place in the tree - for example, ‘$root.$libs.MyLibrary.$menus.MyMenu.’ This concept will be familiar to Frontier users and provides a powerful way of creating and modifying objects at runtime.
Tools paradise Of course, all this is only useful if Omnis Studio’s tools for creating and manipulating objects are up to snuff. Fortunately, they are. The program comes with an entire suite for managing the development process. There are three main tools: the Browser, for creating and managing libraries and adding classes to your libraries; the Component Store, which contains classes and external objects that you can add to your libraries; and the Property Manager, for changing the properties of the objects you create. The Browser lets you view your libraries in three familiar ways: icon, small icon, and list views. All currently open libraries appear in the Browser. To add a new object to a library, simply drag a class from the Component Store.
The Component Store provides you with a listing of all the available classes, templates, Wizards and external components (ActiveX and JavaBeans) you can use in your libraries. Omnis Studio provides probably the best selection of tools for creating interface elements: pop-ups in all flavours, icon lists, tabbed panes, drag-and-drop objects - you name it, it’s there. You can alter the templates, or add your own.
Property market Having created your objects, you will need to change some of their properties. This is where the Property Manager comes in. Anyone who has more than a passing familiarity with Microsoft Access will find this reassuringly familiar. Click on any object in your library and its properties are displayed and can be altered. The real power of this is that external components are tied in so tightly that you can alter their ActiveX and JavaBeans properties and controls using this same editor, as if they were part of the Omnis Studio environment.
In theory, if you believe the manuals, you should be able to create an application using just these three tools. It wouldn’t be much of an application, though. To really get anything accomplished you will need to write extra code - or, at the very least, alter a few objects' methods. The Method Editor is a revamped version of the Omnis7 code editor; as well as letting you change your objects' methods, it’s also where you do the bulk of your debugging. The Method Editor contains panes for displaying the variables for your class and methods, a type-ahead driven list of possible commands and command parameters, a list of current methods, and a watch-variable pane for showing variable values as you trace through your running code. In addition, you can access the Catalog window (which replaces Omnis7’s Field Names window). This lists all the available variables, constants, events and functions, as well as schemas for accessing the data in your SQL databases and hash variables for accessing application properties.
There’s also a SQL Browser that lets you create and view log-on instruction and SQL queries to external databases (which automatically creates Schema and Table classes if you drag your SQL objects from there to the Browser), a Notation Inspector for viewing the entire Omnis Studio object hierarchy from $root downwards, and an Inheritance Tree (C++ programmers would call it a class browser) showing the relationships between the classes.
Manual labour The huge range of library functions and the different ways to tackle the same problem mean you need two or three books to get started. Omnis Studio comes with four manuals - Using Omnis Studio, Omnis Studio Reference, Omnis Cache, and Omnis Studio Conversion. And here we reach the first major problem with Omnis. The Reference manual is a picture of clarity, and the Conversion manual clearly lays out what needs to be done for moving your Omnis7 (and indeed Omnis3 and 5 files) into Omnis Studio. On the other hand, the Omnis Cache manual, which explains how to use and control Omnis Studio’s built-in database, is woefully thin (less than 100 pages for explaining how it all works, how to use it, and the references for Omnis Cache itself). The Using Omnis Studio manual seems to have been written from the point of view of an Omnis7 user who is creating a front end to a database whose files are already in existence and are being hosted by a server application. Both go to great lengths to explain what each object is and what it can do, but regularly neglect to explain why you might use it, and almost universally fail to explain how.
The manuals are very poor for new users. Not once are you taken through the construction of an Omnis Cache database from start to finish. For a product of this quality, this is either a diabolical oversight or a secret plan to freeze the size of the installed user base. In either case, this is the first of the two really major flaws in the system. The second is the pricing structure.
Price sensitive Omnis Studio is more of a front-end development tool than a straightforward database development tool. The program still provides a back-end database of its own, Omnis Cache, but the bulk of the tools and the powerful Wizards are aimed at accessing information from SQL databases, albeit including Omnis Cache. The Omnis pricing, too, reflects this assumption, with three options each for development and deployment.
Omnis Studio (for either Windows 3.1/NT/95 or Mac/Power Mac) is priced at £1299 per developer, per platform - so if you’re developing on a Mac and a Power Mac, you need two copies. Code written on one platform should run on another, but serious cross-platform developers will probably want to have a copy for each platform just to be on the safe side.
If more than one of you is developing the project, then you will probably need to take advantage of the revamped Omnis Version Control System, now called Omnis Studio Production Manager. This has been re-written to handle objects or any piece of code or file (images, HTML pages and so on) you want to incorporate into your project - in fact, you can use it as a standalone tool without including any Omnis libraries or files at all. Omnis Studio Production Manager cost an additional £600.
So far, these costs are what you would expect for as powerful a development tool as Omnis Studio, and when you compare it with other enterprise-size database development tools, it’s excellent value for money. To access a back-end database will require the Omnis Studio Data Access Manager, which costs £1449, although this includes all the tools you need to access any of the Omnis compatible databases - Informix, Sybase, Oracle and ODBC. At that point, runtime access for all of your clients is free. In other words, you only pay for development costs, provided the database you’re accessing isn’t Omnis Cache. Remember, you’re already paying licensing fees for your Oracle or Sybase back-end database.
If, however, you want to use an Omnis Cache database, then you have three choices. You can use the Omnis Dataplayer, which is a read-only database player and costs £12 per user. This option is primarily designed for the CD-ROM market, so you will understand the minimum order of 500 copies (£6000 to you and I). If you need a read/write option, then you have a single-user standalone Omnis Cache package priced at £50, or the multi-user concurrent fileserver licence for £80 per user.
If you start to add it all up you begin to see the picture - £3500 for a single developer-based system using a third-party database (the cost of which is not included) all the way up to £13,500 for a 100-user system with two developers running on two platforms using an Omnis Cache database. Of course, this doesn’t include developers' salaries. But you get the picture.
If you were in any doubt before, Omnis Studio is definitely a major-league product with a pricing structure to match. If you are a large Mac-based or multi-platform company that needs to give its user concurrent access to data, then Omnis is a reasonably priced system. But the emphasis here is on ‘large’. Smaller companies who can’t afford £10,000 in development and deployment software costs will probably see the wisdom in sticking with FileMaker or perhaps opting for a custom solution using CodeWarrior and one of the myriad third-party database engines which have been springing up lately.
Different class Omnis Studio can produce very powerful cross-platform solutions, with superb front-end interfaces. Its object-based approach should improve development time, but the pricing structure and quality of the manuals mean it will probably remain a niche item. Which is a shame, as Omnis Studio-based applications are the sort of business applications that Apple would have killed for two or three years ago.
Omnis Studio fuses awesome power with a database development environment that outclasses anything else on the Mac. Richard Dyce gets down to business.
|Get Further Info|
|Pros||Powerful development Environment ˜ Fully object based ˜ Large selection of GUI elements ˜ Excellent database connectivity|
|Cons||Poor Manuals ˜ Expensive for small to medium-sized companies|
|Originally Published||MacUser, Volume: 14, Issue: 3, p44|