Application Development

The visual object repository is used during development to define and store a set of objects needed to build screens, service components, and reports. Once the repository is populated, you can easily make a new application component by copying the necessary objects from the repository.

In addition to the development time saved by creating objects only once, the repository can be used to easily update application objects by using inheritance. When you copy an object from the repository, the copy, or child, retains the property definitions of the original object, the parent. If you change the properties of the parent object in the repository, the properties that the child has inherited are also updated.

The visual object repository provides:

• A mechanism to assure consistency and control among all application components.

• A single reference for data elements and templates used in an application.

• A facility for propagating database table and column information to your application.

• A single access method for propagating changes to widget and screen properties without having to individually edit each application screen.

About Repositories and Inheritance

A repository can consist of one or more entries; you can create, view, and edit repository entries with the editor. Like Panther libraries, other developers can access the repository concurrently. The repository can provide consistency and control over the look and feel of your application, and its data elements.

By copying an object, such as a text widget, from the repository to your application screen, you create an inheritance relationship between the repository object, or parent, and the application object, or child. If you want to change the object throughout your application, change the parent in the repository entry. The change is then inherited and propagated to the children of that parent repository object throughout your application.

Inheritance propagation happens automatically when you do all of the following:

• Name the parent objects (in the Name property under Identity in the Properties window); imported database objects are automatically named as a result of the import process.

• Copy the named parent widgets to your application screens, or identify the source of inheritance in your screen's and/or widget's InheritFrom property.

• Save the repository entry. Screens, service components, and widgets that inherit from the repository entry are updated appropriately.

You can also propagate inheritance by using the batch inherit utility binherit.

What You Need to Know

The following items represent general information about repositories and inheritance as well as recommendations for using repositories to build applications:

• Although you can have multiple repositories, only one repository can be open at a time. Therefore, it is recommended that you create one repository per application.

• The InheritFrom property identifies the parent source of inheritance.

• Repository entries that are automatically created when you import database tables have the Inherit From property (under Identity) setting of @DATABASE.

• Repositories are a design-time tool. You don't need the repository to run your application.

Using the Repository

One of the first steps in your application development process should be to decide the role of the repository in your application. You need to decide what types of information will be stored in the repository, how that information will be used, and what properties need to be inherited.

Creating the Repository

Create a repository from options found in the editor. Since you can only have one repository open at a time, it is recommended that you create one repository per application. For the steps used to create a repository, refer to "How to Create a Repository" in Using the Editors.

In general, repositories are shared between all members of the development team. Therefore, you want to ensure that all users have access (and permissions) to read and/or write to the repository.

Opening a Default Repository

If the repository is named data.dic and is located in your application directory, Panther automatically opens it when you invoke the editor. You can also set the application variable SMDICNAME to open the repository of your choice.

Creating Repository Entries

Once the repository is created, you can populate it. A repository is like a Panther library, in that it is a collection of screens, service components, and reports that contain frequently used application objects. The screens, service components and reports that are placed in a repository are called repository entries.

There are several ways to create repository entries:

• Choose FileNewRepository Entry.

• Save any Panther screen, report or service component as a repository entry.

• Import your database tables, views or synonyms by choosing ToolsImport Database Objects. This creates a repository entry for each database table.

Creating Repository Objects

When you import database tables, the repository entries contain widgets corresponding to the database columns, and labels corresponding to the column names, but for other repository entries, you might want to create new objects. For example, you might have a repository screen containing push button templates for use throughout the application.

Since repository entries have complete access to all of the editor functionality, you can open a repository entry and make new objects from options on the Create menu. Alternatively, you can copy objects to the repository from any application component.

When you create objects on repository entries, make sure that the parent objects have a value in the Name property (under Identity). It is this name that is used in the Inherit From property in the child object to establish inheritance.

To view the repository entries in the current repository, choose ViewRepository TOC.

Creating Screen Templates

If a series of application screens will share the same screen properties, a repository entry can be a screen template. For example, you might want a series of screens to share:

• Entry and/or exit functions

• JPL procedures

• Control strings

• Menu bars

Another use of screen templates in the repository would be to provide the definition for a screen that is used throughout the application, like an error screen or a dialog box.

Once an application component is created (screen, report, service component), it can inherit properties by setting the Inherit From property to the repository entry. The dialog box asks whether you want to inherit all properties. If you select Yes, all the properties for the application component are taken from the repository entry, overwriting any values you have set. If you select No, the Inherit From property is set to the repository entry but no property values are inherited. You can then set inheritance individually on a property-by-property basis by choosing the Inh button in the Properties window.

The widgets on the repository entry are not copied to the application component, just its properties.

Note: To define the colors for application screens, you might choose to define and edit settings in the configuration map file. Refer to "Configuration Map File" for more information about cmap files.

Storing Database Information

Using the database importer in the editor (ToolsImport Database Objects), you can import a database table with all of its column definitions and primary and foreign key relationships into a Panther repository. If the database engine supports views or synonyms, those database objects can be imported as well.

When you import a database table to a repository, Panther creates a repository entry which includes a label and single line text widget for each column in the database table. The text widget has the column name as one of its properties in addition to other properties that are used for automatic SQL generation. A table view, available through the Widget List or the DB Interactions screen, is created which lists the columns in the database table and the primary key definitions for that database table. A link is created for each foreign key defined for that database table.

Once you have repository entries with your database information, you can copy those widgets to application components or use the wizards to build screens and reports for you.

One advantage of importing your database tables to the repository is that any changes to the database, such as the column length or column type, can be easily propagated throughout the application. The import database facility can be used to update the database repository entries. If the widgets on those screens are the parents of the widgets used in your application screens, changes in the column information are redefined for each child of that widget.

If you are planning to use the transaction manager, it is recommended that you copy the widgets corresponding to the database columns from database-derived repository entries. Repository entries created from the database import facility contain the necessary settings for SQL generation needed by the transaction manager.

Reimporting Your Database Tables

When you reimport your database tables to the repository, you can:

• Add new database columns to the repository entry for that table.

• Update the column length or column type for any database column.

However, if you delete database columns in your database, the widgets corresponding to those columns will not be deleted from the repository entry. You have the capability of adding widgets to a table view; the importer cannot distinguish between widgets that are former database columns and widgets that are table view additions.

Database Import Properties

The following properties are specified via the database import:

Column Edits

A subheading under Database provides access to additional properties that are acquired from the database column as opposed to Panther specifications for the widget.

• Length property—Specifies the column length (as a string) as defined in the database, if available.

• Scale property—Specifies the scale (as a string) of the column as defined in the database, if applicable. Scale determines the length of some numeric columns. This edit is currently unused by the SQL generator.

• Precision property—Specifies the precision (as a string) of the column as defined in the database, if applicable. Precision determines the number of decimal places in some numeric columns.

• Type property—Specifies the column type as defined in the database.

Storing Widget Templates

The repository can contain a master copy of any widget. For example, to use the same push button on several screens, you store a definition of that push button on a repository screen with the color of the push button, the pixmap and the control string that is invoked when that push button is selected. Then you can copy that push button to the applicable screens.

You can define widget templates on a repository entry, or you can copy a widget from one of your application screens to the repository. If you copy a named widget to the repository, the inheritance is automatically set for the widget on the application screen.

Storing Widget Definitions

If several screens share a set of widgets that work together throughout an application, you can create a repository entry for the widget set. In this case, either the widgets involved need property definitions that differ from the database repository entry or all of the widgets in the set are not located on the same repository entry.

First, import the database tables to the repository. Copy widgets from the database repository entry to a new repository entry. The widgets will inherit all the Database and Transaction properties. Set the properties that will not be inherited. Copy the widgets to application screens.

For example, in the Videobiz application, the title_id and name fields are often used together as a scrolling array. Instead of editing the array properties each time these widgets are used in an application screen, the widgets can be copied to a new repository entry, the necessary properties changed, and then the widgets can be copied to an application screen.

Using the Wizards

The first time you create a screen or report with the wizard, Panther copies the following entries into the open repository:

• smwizard—The template for the screen itself as well as the template for several objects found on the finished screen, including push buttons and grid widget.

• smwizis—The template for item selection screens. It contains push buttons and a grid widget; you can modify the properties for those objects or for the screen itself.

• smwizsrv—The template for service components using the JetNet/Tuxedo middleware adapter.

• smwizrw—The template for reports.

• smwizweb—The template for screens with Web-enabled output.

Since objects inherit from these templates, you can change the properties in the repository so that every new screen or report made with the wizard would inherit the desired settings.

If your repository is read-only, the wizard cannot make the necessary entries in the repository. Speak to your system administrator about adding these entries to the repository if you want to use the screen or report wizard.

Using Inheritance

For a screen or widget to inherit from a repository entry, the Inherit From property must be set to the designated object in the repository. This property is set automatically when objects are copied from the repository. For screens, the Inherit From property contains the name of the repository entry, for example, msg_screen. For widgets, the Inherit From property contains the name of the repository entry followed by the name of the object. For example, titles!title_id indicates that the widget inherits its properties from an object whose Name property is title_id on the repository entry titles.

For repository entries imported directly from the database, the Inherit From property for each widget is set to @DATABASE. When those widgets are copied to screens, the Inherit From property changes to the repository entry and object.

The repository object named in the Inherit From property is known as the parent. The widget containing the Inherit From value is known as the child. If a child inherits a property setting which is later changed in the parent, the change is propagated to the child when the screen is opened in the screen editor or after you update the screen using the binherit utility .

An object in the repository can inherit from another repository object. An object on the screen can inherit from only one repository object.

Controlling Property Inheritance

To control the propagation of changes from parent objects to their children, use any of the following methods:

• Turn inheritance off for selected properties by selecting the property and toggling the Inh (Inherit) push button in the Properties window. Highlighted properties will still inherit changes.

  You can reinstate inheritance by selecting the property and choosing the Inh (Inherit) push button.

• Remove the Inherit From property value for the selected application object. Leaving a blank value removes the inheritance relationship for all properties; it does not remove the values. All future changes made to the repository entry are not propagated to the selected widget or screen.

• Choose OptionsInherit to temporarily turn inheritance off. When Inherit is active, the properties of each widget are updated and displayed in the editor as you work. When Inherit is inactive, the properties that are inherited are highlighted, but the values of those properties are not updated or displayed on the screen until inheritance is activated.

  This option is useful if you are in the process of changing or designing repository entries and don't want changes to propagate at design time. When you toggle the Inherit option back on, inheritance is restored and all changes are propagated appropriately to open screens and child widgets that inherit from the open repository.

Updating Inheritance in Application Screens

Use the binherit utility to update screens and reports from property values stored in the repository. binherit can also be used to report on the differences in the properties between the screens/reports and the repository.

Inheritance is updated each time you open a screen in the screen editor workspace and then save it. binherit performs this operation in batch mode, opening specified screens and saving them. Detailed information is located in the documentation for the binherit utility.

Finding the Source of Inheritance

You can find a parent widget or screen (the one that inherits from) as well as find child widgets or screens (the ones that inherit).

The EditFindParent option opens the parent repository entry of the selected object. The EditFindChildren option finds the children of a repository object according to the specified criteria. For more information, refer to "Finding the Source of Inheritance" in Using the Editors.