Managing Development Projects in Genero Studio

Abstract

Although Genero BDL is based on Informix 4GL and both tools can be used to build powerful database applications, there is a world of difference between how a developer will use these tools. In our experience, to get the most out of Genero, it’s vital to have a good understanding of Genero Studio (GST) – the graphical integrated development environment that is shipped with the Genero product. Find out more about managing development projects in Genero Studio below:

Content

Managing development projects in Genero Studio can be complex. They often use or access a variety of pre-built components such as common libraries; they often comprise many modules or application interface definitions; and they often need to provide access to multiple individuals or development teams.

In the article below, we’ve described three key elements that are relevant to the management of a Genero development project:

Project management – managing application development resources and build requirements
Source code control – managing source code access, editing and versioning
Generating an application – building and application using visual design models

1. Project management

When you start up GST your first action is to choose the project to work on and, to keep things nice and simple, you only work on one project at a time.

The project details are stored in a ‘.4pw’ file, in XML format. This is similar in function to the syspgm4gl database in Informix 4GL, but significantly enhanced; it contains full details of all executables, the source and library files they depend upon, compiler options, etc. The content stored in this file is displayed in a very convenient and user-friendly way in GST.

Each Genero executable program (.42r file) in the project is associated with an “application node”. The name of that node is the name of the executable. Each application node contains references to all the components required to build the executable. The files for the application can be added either at the application node level, or into virtual folders within the application node.

Common program functions can be grouped into a library. A library is associated with a “library node” in the project. A project can contain multiple library nodes. If a particular library function is required to build an application executable then the library in question is specified as a dependency in the application node.

Both application nodes and library nodes can be allocated to groups within the project. This might be useful if a number of executables need certain compiler options (these can be specified at the group level) or if the project has discrete components such as command-line or batch processes that need to be logically separated.

2. Source Code Management

Genero Source Code Management (SCM) is built into GST, and enables collaborative sharing and maintaining of the files in Genero projects. It uses Apache’s Subversion (known as SVN), a very widely used source version control system. The core repository stores every version of every file which has been committed back to that repository, so the entire history of your project can be reviewed, as far down as the individual changes to each file; when that change was made; and by whom.

Each developer can create their own branch from the repository (using the Checkout option), and from whichever revision (i.e. a commit) they wish. This will be loaded into a directory specific to that checkout, and once changes have been made they can be committed back to the repository, either all in one commit, or by choosing one or more nodes or elements in the project structure; each commit will create a new revision in the repository, so the full detail of what was done per commit will be available. As part of the commit, SVN will check every file in question, and if there are conflicts (e.g. since your checkout, someone else has made a commit which includes a change to a file you have also changed, and one of those is going to overwrite the other) a notification will be given, and the commit will not take place. You can then resolve that conflict by selecting which commit should overwrite the other, or by changing the code manually, and then the commit can be done.

To help us manage releases in an environment where there are many change requests, we use separate branches for changes that are in progress, and once a release has been deployed and those changes are accepted, all relevant branches are committed back to the repository. Should a bug be reported in the testing phase all we need is a new, separate checkout, which will be from the revision currently deployed to the production environment; we then do the fix, and once it has been verified, commit that change back to the repository. For all the other branches currently in use, we then use the ‘Update’ option – this will review any commits made since that branch was checked out, and unless there are any conflicts, all changes from those commits will be applied to the branch in question. This can be done for the entire project in the branch, at a group level, an application level, or for a specific file, plus you can choose which revision to use for the update.

There are many more functions in SCM, for instance –

Viewing changes at the file level.
- Right click a file in the project, choose SCM, and if you have made a change since the checkout, the ‘Diff’ option will be visible. This then shows your version of the file and the one from the revision used in the checkout, with all new lines, altered lines and deleted lines highlighted separately.

Reverting changes
- Right click any item (project, library, group, application, virtual folder, file, etc.) in the project, choose SCM, and if you have made a change since the checkout, the ‘Revert’ option will be visible. Selecting this will allow you to undo your changes at the level in question e.g. all changes made to a group of applications. Be aware that this cannot then be undone.

Lock files
- If you are making a very significant change to an application or library file, perhaps, a lock can be applied at any level – file, virtual folder, application etc. This will not add a lock to a group for instance, but to all files in all elements of that group. This means that no change to one of those files from another branch can be committed, until the lock is removed; this can either be done manually, or when the file in question is committed.
- Another feature is to add ‘needs-lock’ to a file’s SVN property list. Once that change has been committed, when that file is next included in a checkout it will be read-only, until the user adds a lock to that file, as above. This will ensure that only one user can modify it at a time, and is useful for things like library files containing modules which provide essential functionality, e.g. login validation, database connection, etc.

There are open source GUI tools for SVN, which could, under some circumstances, be helpful, although GST does provide all the required functionality.

3. Generating an application

The Business Application Modeller (BAM) allows you to generate applications from design diagrams rather than writing them from scratch. The default template is for an application allowing the user to add, update, delete and query rows for a table in the database. Such an application is generated by just a few simple steps in GST; setting up the project, creating the business application (BA) diagram, which basically creates a form and relates it to a program (you can have as many as you wish in the diagram), then implementing the programs and forms – each of these steps is a few simple clicks, and a new application will be almost instantly available.

You can easily add extra built-in functionality, and one straightforward option is to include a detail list in a form – if, for instance, the application is for accounts, the form can include a list of all orders for the currently displayed account, and this again can be done in just a few clicks.

Other things that can be added via the BA diagram include:

a ‘zoom’ form, which allows the user to pick a value from a list that is displayed in a form in a popup window;
reports;
web services;
pretty much everything else that the Genero GUI supports

The generated code contains code insertion sections (referred to as either BLOCK or POINT sections). These are defined by lines which appear as comments. Each BLOCK and POINT is uniquely identified, and these are places where you can add your own code, in between the {} and {} comments, and the same for BLOCK sections. They are defined in every appropriate part of the generated code, so you can add global variables, variables in a function, actions in control blocks in interactive statements, functions, and so on. The code you have added is saved in a separate file (.code), which is used each time the application is compiled, so if, for instance, you add some code to a POINT or BLOCK and then make a change at the BAM level (e.g. adding a ‘zoom’ form), when you rebuild the application your code will still be included.

BAM uses default files for tool bars, styles, action defaults, etc. These can be modified or replaced to customise your entire project, or you can use relevant POINT sections to load other files, customising at the application level.

There are templates for the code generation, and these too can be modified, to customise the application’s appearance, work flow, etc. Another useful function is the ability to add POINT sections to the generated code – this is done by modifying the template file for the application in question, and you can then add your own code to those new sections. You can also create your own template files, enabling you to use BAM to create applications with your bespoke style and workflow.

If the executable you are creating is quite complex and/or bespoke, you may be better off writing your own code, but if you need a series of basic maintenance applications then BAM could be an ideal solution, as each is created almost instantly, and they are identical, operationally from the user’s viewpoint, and structurally from the developer’s.

Conclusion

Managing development projects in Genero Studio provides significantly more functionality, user friendliness and productivity for users, where GST Genero has done the same for the developers.

Disclaimer

The above is provided “as is” without warranty of any kind, either express or implied, including without limitation any implied warranties of condition, uninterrupted use, merchantability, fitness for a particular purpose, or non-infringement.