V12 Whitepaper

July 30, 1998
by Paul Hemmer

Today's multimedia applications demand robust data manipulation and user interaction capabilities. To provide such functionality to the end-user, an application must be "smart" in that it should have the ability to store and retrieve dynamic, interrelated pieces of data. Macromedia Director is the leading multimedia development tool for developers with both artistic and programming backgrounds alike. While Director as a development environment is extremely powerful, there are several key areas of functionality which are generally lacking, such as printing, and reading and writing to files.

Many time-critical tasks simply could not be implemented efficiently with Lingo, Director's programming language. Director was originally designed as an interactive animation tool, and as such, does not inherently support some of the more robust functions needed to develop powerful, data-driven applications. However, Macromedia Director is designed in such a way that Xtras, or external components can be developed to extend Director's functionality.

This allows third parties to develop specialized components which enhance the core Director functionality. Developers are increasingly combining the powerful animation engine found in Director with advanced Lingo to develop robust, data-driven applications. As such, the variety of available Xtras for Director is growing every day. There are four main types of Xtras which can be developed for Director. These are Lingo Xtras, Tool Xtras, Transition Xtras and Cast Xtras. Each type of Xtra represents an extension to the corresponding core Director functionality. One key component needed to utilize Director as a robust, data-driven software development application is a database.

What is a Database?

A database is a collection of information which can be structured and sorted. In a database, data is stored in records. Each record represents a collection of fields. For example, when the record keeping personnel at a university are updating a student's course grades, the form which is to hold those grades can be considered a record. Each item on that record (for example, student name, home address, grade point average, year level etc.) represents a field of that record. Each distinct drawer in a filing cabinet that the school's registrar uses to hold student records is analogous to a table in a database. Such a table in a database might be labeled "Grades" as would the filing cabinet in the student records office.

For every table in a database, there can exist one or more indexes. A probable index value for student records would be the last name of the student. In other words, an index represents the piece of information contained in each record which is used when searching for a specific record or records. Upon arriving at the registrar's office of a university, the receptionist would probably ask for your last name and then proceed to search through the filing cabinets which are organized alphabetically by last name. Doing so allows the receptionist to quickly locate your registration information forms. When a field in a table of a database is indexed, the database engine maintains an internal listing of values so that it can search for a specific record quickly. A database simply represents a collection of tables.

Notice that a university does not use one single form to record every piece of information about your student history. Often times several forms will exist to hold the smaller sets of related information your school might need to know about you. It wouldn't make sense to have every bit of your information duplicated on every new form. If such a filing system were in use, one might refer to it as flat, in that every form a school used would contain every piece of information pertaining to each student. A more sophisticated approach would be to break information into separate tables such that related data is stored together in a smaller container, rather than being jumbled in with all the other pieces of data.

If a university uses several different forms, each with a distinct set of related fields, and only the last name in common between the forms, this could be referred to as a relational filing system. In the database world, such a system would be called a relational database. Figure 2 represents the distinction between a flat and a relational database. The flat database on the upper left represents a large table containing every piece of data concerning each student. The relational database to the lower right represents the separation of data into distinct tables, with only one duplicated piece of data acting as a cross-reference between the two tables. In this case, the student's last name would be duplicated on each record, but nothing else.

Such a system makes it easier to manage related pieces of information. More importantly, it allows one to cross reference a single piece of information to a different set of records. For example, the last name of a student on a registration form could be used as a cross reference to locate final exam grades from a previous term in the appropriate filing cabinet. Imagine if such a data management system could be built into your multimedia applications. Suddenly your applications could "come alive" and have the ability to remember and update all kinds of information.

You could develop interactive product catalogs which could be dynamically updated with new product information, current inventory status and pricing information. Full-text indexing features can be used to type in a complete or partial product name and the database could quickly lookup more information such as availability status and pricing and ordering information.

A client could maintain a database of customers and quickly retrieve account status, ordering histories, contact lists etc. One might also want to search for all customers who have ever ordered a given product or for all customers who have placed orders in the past five months for example. A database allows one to search for records based on multiple criteria. For example, a user could easily ask the database for a list of everybody who has ordered "Product A" within the past three weeks. Corporate sales people could use such a system to store presentation materials. A database of presentation slides could be searched and sorted based on dynamic criteria.

For example, all slides containing information about a given product could be quickly retrieved, sorted and displayed. Multimedia training tools, or computer-based training (CBT) products could use such a data management system to maintain student progress information. The administrator of a CBT application could then use the database to perform a search for information relating to a specific student. If such a data management system were a component in your application, the possibilities would be limitless. Fortunately such a database system exists, and it's called V12 Database Engine, by Integration New Media, Inc.

V12 Database Engine

V12 Database Engine (V12-DBE) from Integration New Media Inc., is an Xtra for Macromedia Director which affords multimedia developers the power to satisfy the increasingly dynamic demands of their clients. V12-DBE is used with Macromedia Director 5.x and 6.x. It is fully compatible with Macintosh System 7.x and 8.x, Windows 3.1 and 3.11, and Windows 95. Historically, multimedia applications have been little more than glorified slide shows. Data has been presented to the user through flashy interfaces utilizing colorful graphics, sound and video. Such multimedia applications grab the users attention while presenting to them a predefined information set.

For developers who wish to utilize Macromedia Director to develop mostly static multimedia pieces, the core functionality is quite suitable. However, today's clients are accustomed to the robust, data-driven software applications found on the market today. Increasingly, clients are demanding more from the multimedia applications which they contract developers to produce.

The core functionality provided by Director and Lingo can be used to provide dynamic data storage and retrieval. However, the extent to which such functionality can be used effectively and efficiently is minimal, and the shear complexity of developing such applications using only the core functionality found in Director can become overwhelming. Now with the simple extension of Director with V12-DBE as a dedicated database engine, Director applications can be as robust and intelligent as today's leading applications. When a developer is contemplating the decision to utilize a dedicated database engine as a major component in a multimedia application, several questions will undoubtedly arise.

At a time where data-driven multimedia applications are still outweighed in number by the less robust multimedia "pieces" which generally represent more artistic promotional themes, it can be difficult to see the inherent usefulness of using a database to drive an application. One can't help but ask when and where such an extension could be useful. Any multimedia application relating to games, personnel tracking, interactive product catalogs, inventory tracking, reporting systems or training material is going to require at least a rudimentary level of data storage and retrieval functionality.

Even when such a need clearly exists, developers are often reluctant to turn to a third party component when the job could seemingly be accomplished adequately with Director and Lingo alone. For simple data storage, such as retaining the names and performance scores of a few people in a gaming application, or for storing progress indicators for a few students in a computer-based training application, Director cast members and Lingo can be used quite effectively. However, it is important to note that the ability for such applications to grow and perform properly is restricted by the current state of the application.

While Director cast members and Lingo perform quite suitably when the application specification requires the storage of only a few names and numbers, it is quite possible that in the future the size and complexity of the data being stored will grow. As such growth occurs and the size of the Director cast members needed to store such information grows, increasing demands are going to be placed upon the system to keep up. If any kind of complex queries or data sorting capabilities are required, coding such functionality with Lingo will become overwhelming, as extensive knowledge of the Boolean logic inherent in such data manipulation programming will be required. This functionality is built right into V12-DBE.

On a more abstract level, if a large scale, data-driven application is going to be easily maintained, it will require a high level of system-wide cohesion. This means that data should be stored in a common location and manipulated by a common code base. Taking a less cohesive approach to developing a complex software system will only cause problems when it needs to be debugged or upgraded. When relying on Director cast members and Lingo alone to provide the functionality necessary for such a data-driven application to perform, system-wide cohesion will be reduced as the data is spread across Director casts and associated code is spread across multiple levels of scripts.

V12-DBE represents a simple to use extension to Director which eliminates the need to utilize cast members and custom Lingo code for the data storage and retrieval power your applications demand. V12-DBE acts as the central location in which data is stored, and its associated methods provide a uniform and consistent code base by which data can be accessed.

How does it work?

V12-DBE consists of two Xtras. The database Xtra and the table Xtra. Used together, these two components create a powerful database environment for your Director applications. A single instance of the database Xtra must be used to create a new V12 database or to open an existing V12 database. For each table in your database, one instance of the table Xtra is required. Database files can be created in a number of popular database environments such as FileMaker Pro, MS Excel, MS Access, FoxPro 5.0 or earlier files, 4th Dimension, and Dbase V or earlier.

Files created in any of these database environments can later be imported into a V12 database within the Director environment. V12-DBE is also capable of exporting databases as TEXT or DBF files, which can then be re-opened in many of the popular database environments. The benefit in such a system lies in the fact that databases can be developed and modified in many popular database environments which use a graphical user interface. This eliminates the need to design and implement your databases with Lingo, a task which can be rather daunting to someone lacking advanced knowledge of database structures.

V12-DBE offers several powerful features. V12-DBE is fully scriptable. All V12-DBE features can be used both at runtime and authoring time, except for database creation and cloning, which require a licensed copy of V12-DBE to work at runtime. Tasks such as database creation and data importing can be fully automated. Several easy to use and well documented commands allow you to manipulate and view the records in your database through Lingo scripts. Custom Lingo handlers can be written using the robust set of Lingo methods provided by V12-DBE. Several data types are also supported.

A field in a V12-DBE table can hold values of type string, integer, float, date and media. The format of date values can be fully customized to reflect the variety of formats in which dates are internationally displayed. V12-DBE is unique in that fields of type media can hold pictures, sounds, RTF objects, film loops and any media type that can be stored in a Director Castlib. Fields of type media cannot, however, hold Digital Videos. This is solely due to Director's Lingo API limitation.

V12-DBE supports a number of predefined custom string types, including Swedish, Spanish and Hebrew. Custom string types enable you to sort and compare all single-byte languages properly. Each string type has a predefined set of rules which determine how search criteria will act upon them. Languages such as French, German, Italian and Dutch are naturally sorted properly. Custom string type rule sets are fully documented, which makes it easy to determine exactly how your search criteria will act upon a record set. There's no guessing involved.

Dynamic Data Binding

V12-DBE has the unique ability for Director cast members to be dynamically "bound" to fields in a V12-DBE table. When a Director cast member is bound to a field in a V12-DBE table, the value stored in the field is continuously updated and displayed in the associated Director cast member. In a sense, this represents a "live link" between a field in a V12-DBE table and a Director cast member. Data Binding can be done automatically or at the discretion of the developer. This flexibility greatly enhances the overall appeal of V12-DBE. Once bound, a Director cast member automatically displays and updates the content of its associated field for the current record. This can be extremely useful in that it can eliminate the need to write Lingo scripts to get and set the values of the current record.

Full Text Indexing

V12-DBE tables can be indexed, both by value and with full-text indexes. Indexes are useful for searching and sorting data in large tables. When the size of a record set grows, indexes can substantially increase data access speeds. V12-DBE supports up to 128 indexes per database. V12-DBE uses several operators for implementing full-text indexing.

The Start operator finds all records that start with a given sub-string. For example: "field X starts with hello" locates "Hello world" but not "Say hello!"
The Contains operator finds all records that contain a given sub-string. For example: "field X contains burg" locates "Cheeseburger".
The WordStarts operator finds all records that contain words that start with a given sub-string. Example: "field X WordStarts ham" locates "Great hamburgers", "Green eggs and ham" and "Hammer", but not "Champion". - The WordEquals operator finds all records that contain words that match exactly a given substring. For example: "field X WordEquals ham" locates "Green eggs and ham" but not "Hammer".

An example of an application where such indexing would be useful is an interactive help file. In a help file, the ability for a user to enter a portion of the topic they are looking for, eliminates the need for a user to remember exact phrases or spellings in order to find the desired information. The ability to implement such flexible full-text indexes is extremely powerful, and can prove very useful in many application domains. Searching Querying, or searching for specific sets of data in a V12 database is a somewhat different process than one familiar with conventional database engines might be accustomed to.

The difficult to write SQL statements required in most database environments are replaced by a method called mSetCriteria provided by V12-DBE which allows a Lingo script to define a single record selection criteria. Unlike complex SQL statements required to build search expressions in many database environments, mSetCriteria expressions can be executed in succession to narrow down search criteria. For example, a search could be defined such that records for all customers who ordered a given product between two dates are returned.

As with most database environments, results of search expressions exist as distinct tables.

Such a straightforward process of building and executing search expressions turns even the most complex searches into an easily accomplished task. Following the execution of a database query, the mGetSelection method allows the retrieval of search results as Lingo lists - both regular lists and property lists. This makes the Lingo based manipulation of search results extremely easy.

Error Detection and Defensive Programming

V12-DBE provides powerful error detection capabilities. Two methods, V12Status and V12Error can be used to confirm each step of database creation and handling. By following each call to a V12-DBE method with a call to these methods, a developer can use Director debugging tools such as the Watcher and the Debugger to precisely pinpoint any problem areas in his or her Lingo scripts. V12-DBE is designed in such a way that all calls to V12-DBE methods will return a code that can be interpreted by V12Status and V12Error.

This can provide comprehensive information pertaining to what might have gone wrong when a call fails. Generally these two methods are used together in a single checkError() function which can be called after each call to a V12-DBE method. The error checking tools provided by V12-DBE are invaluable during the development process for tracking down errors and raising an alert when an error does occur.

V12-DBE Behaviors for Director

V12-DBE Behaviors Library allows a developer to simply drag and drop database functionality into multimedia applications to create simple database-driven user interfaces without writing a single line of Lingo code. These Behaviors make it simple for any developer, regardless of his or her level of Lingo knowledge, to implement any of the features of V12-DBE needed to incorporate it with a Graphical User Interface.

V12-DBE Samplers

Integration New Media makes available several "Samplers" on their web site (http://www.integration.qc.ca/downloads) which serve to illustrate key concepts, and stimulate creative insights into possible applications of V12-DBE as an extension of the Director development environment. There are several types of functionality common to most applications utilizing a database, and sample movies are available to illustrate the following concepts :

Performing searches and displaying results as each letter in a keyword field is typed, as in help file indexes.
Full-text indexes using V12-DBE.
Displaying and browsing multiple fields of a single record at once.
Importing external media files.

These represent only a few of the Samplers provided by Integration New Media, Inc. on their corporate web site. Integration New Media encourages members of the V12 community to make contributions to the site such that other developers can see what new techniques are being utilized to use V12-DBE to it's fullest capacity. V12-DBE is an extremely powerful, comprehensive, user friendly and cross-platform database engine designed for use with Macromedia Director. Vahe Kassardjian, President of Integration New Media states:

"V12 allows one to structure his work from the start, therefore cutting out an unbelievable amount of programming time, leaving more time for creative effort, as well as allowing for rapid updates."
As a powerful extension to Director, V12-DBE truly is the missing link needed to make your multimedia applications come alive.

Paul Hemmer received a BS in Information Technology from Rochester Institute of Technology. He is Senior Developer for a Rochester NY multimedia company. He primarily does Object Oriented Lingo development and lately has doing quite a bit of ASP programming. Paul is very much an advocate of OOP and always tries to push Director beyond its limits. He is committed to increasing awareness of the power and importance of the object oriented mindset and he does his best to make sure everybody on DirectL knows how he feels. Paul's real love is music. He is a bass player who happens to enjoy slinging Lingo by day. ;)