Progress4GL to CSharp conversion: Difference between revisions

From OpenPetra Wiki
Jump to navigation Jump to search
(Created page with 'some links: *https://sourceforge.net/projects/progress4gl2cs/: This source code converter translates Progress4GL code (e.g. Progress9, OpenEdge) into C# code ** this is not a wo…')
 
mNo edit summary
 
(2 intermediate revisions by the same user not shown)
Line 1: Line 1:
some links:
==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.


*https://sourceforge.net/projects/progress4gl2cs/: This source code converter translates Progress4GL code (e.g. Progress9, OpenEdge) into C# code
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.
** 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#




*http://www.joanju.com/proparse and http://www.oehive.org/proparse/ Generate a Source code tree of Progress4gl code
===Overview of PROGRESS 4GL===
** using http://www.antlr.org/
Please see [[http://en.wikipedia.org/wiki/OpenEdge_Advanced_Business_Language 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).




Use for OpenPetra:
 
* We have a lot of code of the old Petra still written in Progress 4gl.
==Scope for Automatic Code Conversion==
* The problem is that we need the new code to access our own typed Datasets.
''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.''
* One approach could be to parse the current .w files (graphical user interface files) and generate a yml file which can be used to generate the new screen for OpenPetra
 
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 [https://sourceforge.net/apps/mediawiki/openpetraorg/index.php?title=Development_with_Code_Generation#YML here] for a short overview and [[https://sourceforge.net/apps/mediawiki/openpetraorg/index.php?title=Documentation_GUI_generation_with_YAML#current_features 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 [mailto:info@openpetra.org 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===
* http://www.joanju.com/proparse and http://www.oehive.org/proparse/
** Generates a Source code tree of Progress4gl code using [http://www.antlr.org/ ANTLR]
** This is not specific to PROGRESS 4GL GUI Code.
* Write a completely new Parser for [http://www.antlr.org/ ANTLR].

Latest revision as of 13:07, 12 April 2010

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