Summary:
You typically use Genero to build an interactive database application, a program that handles the interaction between a user and a database. The database schema that organizes data into relational tables gives shape to one side of the program. The needs of your user shape the other side. You write the program logic that bridges the gap between them. You express the logic of your application with Genero BDL statements in program source files.
The main feature of Genero is its separation of application business logic from the user interface. The language supports embedded SQL instructions to access the database, and the user interface can be manipulated at runtime, as a tree of objects called the Abstract User Interface (AUI).
Genero BDL is a language compiled to p-code, which can be interpreted on different platforms by the Dynamic Virtual Machine (the Runtime system).
By separating your application business logic from the user interface, Genero provides the ability to support different kinds of display devices using the same source code.
Another important feature of Genero BDL is the ease with which you can design applications that allow the user to access and modify data in a database.
For additional information, see SQL Programming.
The Localized Strings feature allows you to customize your application for specific subsets of your user population, whether it is for a particular language or a particular business segment.
You can easily design and generate Reports:
Genero BDL is a high-level, fourth generation language with an open, readable syntax that encourages good individual or group programming style. You write your program logic in text files, or program source modules, which are compiled and linked into programs that can be executed by the Runtime system. Programs are easily enhanced and extended. This makes it easy for programmers to become productive quickly, no matter what programming languages they know. See Programs, Flow Control, Functions for additional information.
Writing the code for many of the tasks associated with interactive database applications has been simplified for you in Genero BDL; single statements automatically compile into the lines of program code required to accomplish the task. Interactive statements, known as dialogs, allow the program to respond to user input. For example:
In Genero, programs manipulate Window and Form objects to define display areas for interactive statements within your program. The Abstract User Interface (AUI) tree contains a definition of these objects. You can open as many windows and forms as needed, subject only to the limits of memory and the maximum number of open files on the platform you are using.
The OPEN WINDOW statement creates and opens a new window on the user's screen. The runtime system maintains a stack of all open windows. When you execute this statement to open a new window, it is added to the window stack and becomes the current window.
You can modify the window stack with the CURRENT WINDOW and CLOSE WINDOW statements.
With the OPEN WINDOW ... WITH FORM statement you open a window on the screen, load a compiled form from disk into memory, and make it ready for use.
The DISPLAY statement allows you to display program variable data in the fields of a form, for example, and then turn control over to the user for his subsequent action.
The interactive DISPLAY ARRAY statement allows the user to view the contents of an array of records, scrolling the records on the screen.
The INPUT statement is an interactive statement (dialog) that enables the fields in a form for input, waits while the user types data into the fields, and proceeds after the user accepts or cancels the dialog. If the user accepts the dialog, the input that is automatically assigned to program variables can be used by your program to insert rows or change rows in a database, for example.
The interactive INPUT ARRAY statement allows the user to alter the contents of records in a screen array, and to insert and delete records. Your program can control and monitor these changes.
Genero BDL lets you take input from the user in more than one way; instead of literal values for the program to process, your user can enter search criteria for a query. The interactive CONSTRUCT statement allows the user to enter a value or a range of values for one or several form fields, and your program looks up the database rows that satisfy the requirements. You provide a single program variable to hold the result of the CONSTRUCT statement. Your program can combine this Boolean expression string with other text, to form a complete SELECT statement to fetch the desired database rows.
What you do with the fetched rows depends on the specific application. Often the reason for the CONSTRUCT is to select rows to be viewed by the user. In this case, the program could display each row individually in a form or grouped in a screen array; or, you might choose a set of rows for a report or a set of rows to be deleted or updated.
You can define a program routine (set of instructions) that is triggered by the user's actions. The actions can be displayed to the user as action views - buttons, toolbars, or pull-down menus in the application window. When the user makes a selection, the corresponding action is executed.
The interactive MENU statement can be used to define the list of actions that can be triggered. Or, the ON ACTION clause of interactive instructions, such as INPUT, INPUT ARRAY, CONSTRUCT and DISPLAY ARRAY, can be used to list the program routine to be executed for a given action.
Common actions, such as accept (dialog validation) and cancel (dialog cancellation), are already pre-defined for you according to the interactive instruction; you do not have to define them for each dialog.
Action Defaults allow you to define default decoration attributes (text, image) and functional attributes (accelerator keys) for the graphical objects associated with actions.
The end-user of a program does not know about the database schema or your carefully designed program logic. As the user sees it, the forms, and the menus that invoke them, are the application. The arrangement of fields, labels, and other form objects, and the behavior of the form as the user presses different keys or buttons and selects different menu options, create the personality of the program.
Forms are portable across applications and platforms. The XML-based application screen can be defined in form specification files; since form files are separate from the other parts of your program, the Runtime Form Files can be used with different programs.
You can design your form to group objects in horizontal and vertical boxes, display it as a folder of pages, and use menus, toolbars, or buttons to trigger actions. You can associate an array of data in the program with an array of fields on the form (screen-array), so that the user can see multiple rows of data on the screen. In addition to the form fields and screen records, your form can contain objects like progressbars, checkboxes, radiogroups, comboboxes, and images.
The appearance of form objects can be standardized using Presentation Styles and Action Defaults.
You can define the application screens, or forms, in text-based Form Specification Files (.per) These form files are translated by the Form Compiler to produce the Runtime Form Files (.42f) that are deployed in production environments. Unlike compiled program files, the translated Runtime Form Files are XML documents that describe the form elements, enabling portability across display devices. The XML file can also be written directly, or it can be generated or modified from your program code using the methods provided with Genero Built-in Classes.
The Genero Runtime System creates the Abstract User Interface tree, and the Genero Front End makes this abstract tree visible on the screen. When a user interaction statement takes control of the application, the copy of the tree on the Front End is automatically synchronized with the Runtime system tree by the Front End Protocol, an internal protocol used by the Runtime System.
Default XML files describe the appearance (decoration) of some of the graphic objects on the user's screen:
These files may be customized, or replaced with your own versions.
A special StartMenu, used to start different programs on the application server where the runtime system executes, can be defined in an XML file with the extension .4sm.Your Genero BDL program can consist of a single source code module, but generally you will have multiple modules as well as form specification files and perhaps localized string files. Database schema files are also required, if you have defined program data types and variables in the terms of an existing database column or table by using the DEFINE ... LIKE statement.
The tools that Genero provides to compile the various files that will make up your application, and the file extensions of the source code and corresponding compiled files, are listed below, and an explanation follows:
The compiled source code modules can be linked into a program that can be executed by the Runtime System, or into a library that can be linked into other programs.
Database Schema Files are used during program compilation to define data types, default values, display attributes and validation rules for form fields and program variables. You must generate database schema files each time the database structure changes, before compiling any other parts of your application.
The SCHEMA statement in program source files and form files identifies the database schema file to be used. The FGLDBPATH environment variable can be used to define a list of directories where the compiler can find database schema files.
The Schema Extractor (fgldbsch) is the tool provided to generate the database schema files from a real database. Database schema files are generated from the system tables.
Example:
fgldbsch -db <database_name>
It is important that the schema file of the development database corresponds to the production database; otherwise, the elements defined in the compiled version of your modules and forms will not match the table structures of the production database.
The primary file produced by the utility is:
<database>.sch - the file containing the data type definition of all columns selected during schema extraction.Genero BDL provides its own source code compiler, which generates hardware-independent pseudo-machine code (P-code). This code is not directly executable by the operating system; it is interpreted by the Genero BDL runtime system (usually a program named fglrun, and called "runner"). If a custom runner with any other name than fglrun has been created, you must set the FGLRUN environment variable.
The compiled P-code modules are binary. The files are not printable or editable as text.
This tool compiles a program source module into a p-code version. The compiled module has an extension of .42m.
If a compilation error occurs, the text file <filename>.err flagging the errors is created. You can directly display the compilation errors by using the -M option.
Example:
fglcomp <modulename>.4glRunning the program:
fglrun <modulename>.42mIf your program consists of more than one module, the modules must be linked together prior to execution, using the fgllink tool.
This tool assembles multiple p-code modules compiled with fglcomp into a single .42r program or a .42x library.
Example to create a program:
fgllink -o <programname>.42r <module1name>.42m <module2name>.42m ...
Running the program:
fglrun <programname>.42r
Example to create a library that can be linked into other programs:
fgllink -o <libraryname>.42x <module1name>.42m <module2name>.42m ...
Example to create a program:
fgl2p -o <programname>.42r <module1name>.42m <module2name>.42m ...Example to create a library:
fgl2p -o <libraryname>.42x <module1name>.42m <module2name>.42m ...
Form specification files are used by the Form Compiler (fglform) to produce the Runtime Form Files that are deployed in production environments. The form files have an extension of .per . Unlike compiled program files, the generated Runtime Form File is an XML document that describes the form elements. The Runtime Form Files have an extension of .42f.
If a compilation error occurs, the text file <filename>.err flagging the errors is created. You can directly display the compilation error by using the -M option.
Example:
fgflform <formname>.per
The fgl preprocessor can be used with the 4gl compiler and the form compiler to transform your sources before compilation, based on preprocessor directives. It allows you to include other files, to define macros that will be expanded when used in the source, and to compile conditionally.
See The FGL Preprocessor for details.
Source String Files (<filename>.str ) containing the text of the Localized Strings that are used in your application must be compiled to binary files in order to be used at runtime. By default the runtime system expects that the Source String file will have the same filename as your program. The compiled file has an extension of .42s.
Example:
fglmkstr <filename>.str
To assist you in creating the Source String Files, the -m option of the fglcomp and fglform tools extracts all the localized strings that are used in your source code modules and forms.
Example:
fglcomp -m <modulename>.4gl
The output file will be <modulename>.str . This extracted file can be edited to assign text to the localized strings, and combined with other extracted files into a single <programname>.str file.
Note: Windows or Unix-based makefiles may be used to automate the process of compiling and linking programs.
The following program files must be deployed at the user site:
The following BDL documentation is available for your reference:
Business Development Language Manual (User Guide) - complete guide to Genero BDL language features, with explanations and sample code.The following pages from the User Guide may be especially helpful in understanding the concepts underlying Genero BDL:
The following pages from the User Guide may be especially helpful if you are migrating an application from an earlier product:
Genero training classes are also available. Please call your regional sales office for information.