OMNIS Studio 2.1 Achieving Omniscience

As featured in:
Component
Online Strategies
July 1999 US Edition.

Author: John Hunt, Component Strategies Magazine.
Dr. Hunt has extensive object-oriented experience and has been involved in developing Java applications and delivering numerous Java courses to both academia and industry. He can be contacted at jjh@aber.ac.uk.

OMNIS Software (née Blyth) first produced the product that evolved into OMNIS Studio more than ten years ago, when 4GLs for relational databases were just getting going. Few such tools were cross-platform at that time, although OMNIS was an exception. OMNIS Studio 2.1 is the latest incarnation of this product family, and although it was tested in beta form, it is certainly impressive. It provides simple, easy-to-use wizards, which automate almost every step in the creation of a relational database application. Such applications can be deployed as standalone programs, client/server systems, or Web applications.

This means that producing a Web-based interface to a database is easy with OMNIS. I could do the same thing in Java, but it would take a great deal longer. The impressive speed of development comes from a combination of the wizards and the inherent code generation capabilities of the tool. The end result was that an application was designed interactively and deployed in about half an hour. Speed of development is, thus, one of OMNIS’s strongest points.

Not only can you build the user interface for a database application quickly and effectively in OMNIS, you can also build the databases on which these applications rely. Again the tools provided in OMNIS mean that the databases can be designed interactively almost in a matter of minutes, depending on the complexity of the application. For example, if we wished the window layout to be based on the fields in a database, OMNIS can generate an appropriate window with default labels for input fields automatically. It is then merely a case of typing in more user-friendly labels. This takes very little time.

OMNIS does not compile to native code. Instead, it offers a highly portable runtime environment that executes the intermediate form of the OMNIS language. A system developed on a PC can be deployed on Windows 95 and NT, UNIX, Mac OS, and OS/2 without any modification. The cross-platform nature of the applications, like the cross-platform nature of Java, is a compelling reason to use OMNIS. You avoid the need to implement, maintain, and support different versions, and it also makes it easier to document. You also get the benefit of working with a 4GL rather than with a 3GL like Java.

As would be expected from a 4GL aimed at producing application interfaces for relational databases, OMNIS studio provides excellent integration with database vendors via its Data Access Modules (or DAM). DAMs are provided for all the leading database vendors including Oracle, Sybase, and Informix. In addition, access is also provided to ODBC, thus enabling any ODBC-compliant database to be integrated with an OMNIS front end.

Application development in OMNIS is based around the concept of a library. A library could be viewed as a project or, more appropriately, like a package. A library contains the classes, tables, and tasks associated with a single element of an application. Just as with any object-oriented environment, a developer uses classes to create instances. Instances can possess data (properties) and methods. Instances communicate via message passing or by events. The final element in the jigsaw is a task that executes the application, holding the instances and running the methods.

OMNIS is based around the familiar OO concepts of classes, instances, attributes, and methods. It includes classes for windows, menus, toolbars, and report generation, lists and grids, as well as a set of Internet classes. However, much of the time you do not need to get down to the code level, you merely create classes and instances of the classes interactively for your application. As mentioned earlier, the various wizards provided simplify this process greatly. For example, the OMNIS Remote Form Wizard is used to design a form for a Web page interactively. It means that the user need never get near the HTML used to define the Web page or the OMNIS programming language that defines the logic and creates the actual OMNIS form.

In low-level development situations, such as method definition, you use the OMNIS programming language, called notation. This language has some esoteric features, but with practice you can quickly write very powerful, compact code. This is partly because of the language itself and also the interactive editing tools that provide keyword expansion and interactive keyword selection. The esoteric features of the language relate to notation. For example, all property names start with a dollar sign to distinguish them from things like the name of a library or a class name. Properties are things like name, width, alignment of an object, etc. For example, $name and $align. Tasks, classes, and objects can also have properties. As with other OO environments, class variables are associated with a class, and there is only one copy in the system, which is held inside that class. For an instance property, there is a copy held in each instance. Properties can be of the normal range of data types, including Character, Number, Boolean, Date Time, Sequence, and List (a structured data type that holds multiple columns and rows of data of any type). Other property types include Row (a structured data type that holds multiple columns of data in a single row) and Object. Properties of type Object are instances based on any class currently available (both system provided and user defined).

Method names also begin with a dollar sign, but also include round brackets (which distinguish them from properties), for example $open(). In addition, object names start with a $ and the whole system is rooted on an object called $root. In turn, all menus are stored in the $menu group, all report classes are in the $reports group, and all toolbars are in the $toolbars group. If you wish to reference a particular object within a particular library, or a method, on a class or a property you do so by linking the various types of objects together via full stops, e.g.:

$root.$libs.EmployeeBrowser. $window.DisplayWindow

This would refer to the DisplayWindow of the EmployeeBrowser library. To get to a particular object on this window, we would need to add the $obs group and the name of the object to this string:

$root.$libs.EmployeeBrowser. $window.DisplayWindow.$obs.text

The structure is such that libraries are always contained within the $libs group under the $root. Windows are always held in the $windows group of a library and objects are always in the $obs group of whatever they are referenced by. This structure becomes more familiar as you work with it. There are also a number of shortcuts that mean you don’t always have to refer right back up to the $root object. These all relate to the current object or instance that it is executing. Mostly their names begin with $c and include $cdata for the current open data file, $ccinst (for the current instance) and $cclass for the current class. By referencing these objects it is possible to shorten the full path name that is used to identify a property or method. For example, rather than the full path presented above we might use:

$cinst.text

Most methods can be executed using the do command. So, to open a window you could use the do and the $open() method.

A method editor and debugger is provided to support the development of methods. The method editor is illustrated on the next page, where it is being used to define the $construct() method of the Startup_task for the OO application. A $construct() method is like a constructor in Java, because it is executed when the instance is created and is used to initialize the instance. Notice that in the bottom left-hand corner of the editor, all the language constructs are listed. When the user selects one of these they are added into the text window and any additional information prompted for in the lower right hand area of the method editor. Another attractive feature of this editor is that command completion is provided, thus allowing the user to type only part of a command before it is filled out automatically. Interestingly, the method editor limited a method definition to 240 separate lines of code (not including comments), thus forcing developers to keep methods simple.

OMNIS also possesses another type of method, in the form of an event method. There are two such event methods, one called $event() for windows, menus, and toolbars, and another called $print() for report fields. These are methods which are called in response to an event being generated (such as a user clicking on a button). Events are detected in the OMNIS event handling mechanism using the On command plus the appropriate event message. For example On evClose or On evMoved (notice that all event methods start with ev). Any code you define after one of these event handler statements within the $event() method will be executed when that event occurs.

One of the new features of this release of OMNIS studio is the OMNIS Web Client. This makes it possible to deploy an OMNIS application over the Web. Developers can create Web forms using drag- and-drop selections, wizards, and controls such as drop-down lists, tabs, and sidebars, in just the same way as they would if they were creating a form for a non-Web application. The Web form is an OMNIS remote form class, just as an applications window is a type of class. It is just the way that they are deployed that differs.

Once deployed, the server part of the OMNIS application resides on the Web server and sits between the Web server and the database, in much the same way as a Java servlet might sit between the Web server and a database. The user then accesses a Web page that contains references to OMNIS. If this is the first time that the user has done this they are prompted to download the OMNIS Web client plug-in for Netscape or an ActiveX component for Internet Explorer. Once this is installed they can access Web pages that use OMNIS and can communicate between the client and the OMNIS server engine. The client and the server then communicate using standard HTTP or HTTPS protocols.

The first time that a user accesses an OMNIS-aware Web page they will have to install the client engine, which will take time, and cause a bored user to jump to another Web page. Typically, the Web server would provide an HTML page from which the user can download the ActiveX or Netscape plug-in, or alternatively an automatic installer can be used. However, once downloaded they do not have to do this again and certainly for an intranet or similar, part of the system setup could include installing the appropriate plug-in or ActiveX component. The actual plug-in is around 500 Kb and therefore is not excessively large. The ActiveX and Netscape plug-in come with a number of additional DLLs. These provide the form and GUI engine of the Web client. Others are external component DLLs that provide the controls and background objects used on forms.

Having a local OMNIS Web Client allows the interface presented to the user to be more than just basic HTML with fields, buttons, and the like. It also means that no separate scripting language is required to provide for operations such as local verification of user input. This means that developers can stay within a single environment for the development of the client-side and server-side elements of the application. However, if developers wish to provide their own controls to add to a Web page, they need to implement this in C++ using the open external component interface.

The controls on a form (for example buttons) can generate events, these events can be handled locally within the Web client or they can be handled by applications running on the Web server. To reduce the amount of network traffic generated when an event is fired, developers can indicate which are local and which are not. Only those intended for the server application are then passed to the server.

In addition to the built-in components provided as part of OMNIS, it is possible to import components written outside OMNIS, such as ActiveX, JavaBeans, and C++ controls. This is done by adding these components to the Component Store (a palette of available components and wizards). Once these new components have been added to the component store they are available for use within an application in just the same way as the OMNIS components.

OMNIS Studio also possesses its own version control system, called VCS. This can handle the core OMNIS components such as libraries and data files, but can also incorporate external code, components, such as JavaBeans and ActiveX, and text fields. It also provides facilities for configuration management and version control. It also possesses team-oriented access, thus ensuring that only one person is modifying an application element at a time.

One aspect of OMNIS that I did not like was the number of windows that could very easily be generated during development and the extent to which I wanted them all visible at the same time. Using a 17-inch monitor with the highest resolution, I still found I wanted more space on the screen.

Overall, OMNIS Studio 2.1 is an excellent 4GL, RAD development tool. It possesses an esoteric but powerful programming language and really needs large monitor support. However, it does provide a lot of wizards and wizard-like facilities combined with a drag-and-drop style development environment that produces database and Web-oriented database applications very quickly. As long as what you want to do fits this particular 4GL, then OMNIS Studio is an excellent choice.

– John Hunt