Progress4GL to CSharp conversion

From OpenPetra Wiki
Jump to navigation Jump to search

Background information about Petra's Programming Language and Source Code

Petra is the program that OpenPetra will eventually replace. It is built with a language called PROGRESS 4GL.

We estimate that about 80% of all Petra 2.3 code is still in the 4GL language (as of April 2010). This estimate is based on Physical Lines of Code count (LOC) and a look at the different source file types. The rest of Petra 2.3 (approx. 20%), including the new Client/Server infrastructure with our in-house developed cross-platform Application Server, is done in the programming language C# 2.0, and uses the .NET 2.0 Framework.


Overview of PROGRESS 4GL

Please see [this] Wikipedia article for an overview. The language has been renamed and extended from version 10 onwards, but the examples given on the Wikipedia page looks very similar to the PROGRESS 4GL language (we are using PROGRESS Version 9.1E, and therefore also the 9.1E language 'flavour' of PROGRESS 4GL).


Scope for Automatic Code Conversion

The more we work with translating PROGRESS 4GL code to C#, the more we realise that an automatic code conversion makes sense only in a few, limited cases.

This has many reasons. One reason is that quite a lot of Petra's DB access code looks cumbersome today and should definitely be rewritten. This is partly so because when the source code was written (which can be as far back as 10-15 years), CPUs were so much slower that today and PC's RAM capacities were really small compared to today's PC's RAM capacities. For this reason temporary DB tables were employed quite often, which is hardly necessary today. Also, SQL is quite different in its capabilities compared to the PROGRESS 4GL data access language. OpenPetra employs a Data Access Layer (or Object Relationship Mapper [ORM]) for accessing most of the DB data in an elegant and typesafe way, whereas the PROGRESS Code utilizes PROGRESS 4GL-specific syntax to access the DB. Therefore, data access code is quite hard to map automatically, and often impossible, we think.

Furthermore, the C# language has quite a few constructs that PROGRESS 4GL lacks, some of them very basic (such as Arrays…) and this can make quite a difference to the approach of a solution for a particular functionality or algorithm. Not to mention that PROGRESS 4GL is a Procedural Language and that C# is an Object Oriented language, and that the architecture of Petra's 4GL parts is not a client/server architecture, whereas OpenPetra's architecture is a client/server architecture.

There are many other aspects which make an automatic or even semi-automatic code conversion very hard - to the point that we believe it might be more work to get such a conversion program right than rewriting code manually from scratch (of course only after having done a thorough analysis of the 4GL code and having worked out how to best do it in C# and OpenPetra's client/server architecture).


That said, there are areas where automatic or semi-automatic code conversion could speed up development of OpenPetra.

We have not yet fully identified all areas where automatic or semi-automatic code conversion would make sense, but one area that would seem to give a good cost-benefit ratio is the automatic translation of PROGRESS 4GL GUI code.


Automatic Translation of 4GL GUI Code

This would be translating only a part of the PROGRESS 4GL code, namely the part that is responsible for specifying e.g. which TextBoxes go where on the screen, which DropDown/ComboBox controls would use which lookup tables, which Buttons would be where on the screen, the general type of a screen (Edit, Browse, Find, etc.) and the bindings of the Controls to the underlying data scheme.

Only a part of Petra 2.3's 4GL Forms would be a candidate for automatic GUI translation, though, because we intend to implement quite a few 4GL Forms in an entirely different manner than they are implemented currently. There are few reasons for that. One reason is that there are better ways of doing it nowadays (more screen real estate, newer controls (e.g. TreeViews, collapsible Panels)), another reason is consolidation of the functionality of several screens into one screen (e.g. using Tabs), or the change of approach in an entire functional area of Petra, which will result in quite different screens.

OpenPetra GUI Definition Files

OpenPetra uses yml files (a simplified version of xml files, see here for a short overview and [here for details) to specify the screen layout of OpenPetra screens and utilizes a Generator to create the WinForm files out of those yml files (this is done at design time).

Anticipated Benefit

We anticipate that an automatic generator which would translate 4GL GUI code into yml files would be beneficial in getting the initial layout of a Petra screen and the data bindings of the fields of the screen over to OpenPetra. Through this, potentially a good number Petra screens could be at least prototyped quickly for OpenPetra. This would save some time, and more importantly rid the OpenPetra developers of a mundane task.

Suggested Approach

Petra 2.3's PROGRESS GUI code utilizes only a small subset of the PROGRESS 4GL language and is rather easy to read. Therefore it should not be too complicated to come up with a Parser for PROGRESS 4GL files that would work solely on the GUI part of source code files and would derive each screens' layout and screen type out of this. A Generator that would take the parsed result and would create OpenPetra's yml files in the correct directories also seems feasible.

Participation

If you are interested in helping with the automatic translation of 4GL GUI Code, please don't hesitate to contact us at info@openpetra.org.


Code Conversion Approaches

Historic

  • https://sourceforge.net/projects/progress4gl2cs/
  • This source code converter translates Progress4GL code (e.g. Progress9, OpenEdge) into C# code
    • This is not specific to PROGRESS 4GL GUI Code.
    • This is not a working software. It uses the same parsing routines as the converter that we wrote for the conversion from Delphi.net to C#

Potentially Workable