Explanation of Directory Structure and Rules
This article describes the existing folder structure of the source code, and gives a short description of the contents and purposes.
See also the detailed documentation of the source code, generated from the in-code comments.
C# Source Code
All C# Source code is found in the subdirectories of the
Some Third-Party tools and DLL's are found in subdirectories of the
csharp/ThirdParty. Their license is compatible with the GPL, and each directory has a text file with the licensing details and links to the origin of that software.
csharp/ICT/Common contains some general libraries, e.g. for connecting to different Relational Database Systems, a printing system, String Helper functions, etc.
This contains code that is used to encrypt the communication between Server and Client, using a public/private key mechanism.
This contains several tools for generating code, some NAnt extensions for executing operations on the database, and much more. The resulting EXE's and DLL's are not shipped with an installation of OpenPetra, except for the
Various Unit Tests and Integration Tests are found in subdirectories of this directory. The resulting EXE's and DLL's are not shipped with an installation of OpenPetra.
The subdirectories under the
csharp/ICT.Petra directory contain most of the C# source code that make up the OpenPetra application. The only other directories that contain such source code are the
The code in directory
csharp/ICT/Petra/Shared is intended to be shared between Server and Client. This means that no access to the database is available through Classes in these files since the Classes can be used on the client side as well, and the Client side does not have direct access to the OpenPetra database.
csharp/ICT/Petra/Shared/lib/data contains Typed DataTables which match the definitions of the database tables. A Class exists for each OpenPetra database table. A programmer uses Typed DataTables to hold data relating to database tables in memory (details can be found here); these Classes can't be used to access the database, though (that's what the DataAccess Classes are for). The Typed DataTables C# Classes are generated automatically, using the
nant generateORMdata command. This directory contains generated code for all OpenPetra Modules.
csharp/ICT/Petra/Shared/Interfaces contains C# Interfaces for functionality that the Server offers to the Client. Most of the interfaces are generated automatically, using the
nant generateGlue command. This directory contains generated code for all OpenPetra Modules.
A subdirectory exists for each OpenPetra Module, e.g.
csharp/ICT/Petra/Shared/MPartner, which contains C# files that define shared Constants and contain shared routines for that OpenPetra Module. These can be used on both the Server and the Client side.
Under each OpenPetra Module subdirectory there is a 'data' directory which contains definitions of Typed DataSets for that OpenPetra Module, e.g.
csharp/ICT/Petra/Shared/lib/MPartner/data. These C# Classes are generated automatically, using the
nant generateORMdata command. More documentation on this will follow.
csharp/ICT/Petra/Shared/MReporting is not a true mapping to an existing OpenPetra Module that the user knows of. It contains reporting functions that are used across all OpenPetra Modules. These can be used on both the Server and the Client side.
csharp/ICT/Petra/Server/app contains code that is necessary for the basic operation of the OpenPetra Server, e.g. Client connection, loading and maintaining AppDomains for each connecting Client, connecting to the database, etc.
The main PetraServerConsole.exe is compiled from a project in
csharp/ICT/Petra/Server/lib/data contains generated C# Classes for accessing the database, so-called 'DataAccess Classes'. Details about the DataAccess Classes can be found here and information on how to use them can be found here.
csharp/ICT/Petra/Server/sql contains a couple of more complex SQL queries which are much easier to read this way than encoded in strings inside the C# code.
A subdirectory exists for each OpenPetra Module, e.g.
csharp/ICT/Petra/Server/lib/MPartner, which contains C# files that contain most of the Business Logic of OpenPetra.
The 'Module' subdirectories contain further subdirectories (not all need to exist for every Module!):
- \Module\connect subdirectory: contains auto-generated Instantiators and any manually written UIConnectors
- \Module\web subdirectory: contains WebConnectors
- \Module\query subdirectory: contains Classes that execute (potentially a series of) database queries that are based on Parametrized SQL queries rather than our DataAccess Methods (usually these Methods load SQL files using Method 'TDataBase.ReadSqlFile'). The reason why this is done is either complexity or speed, or both. Also, memory consumption might be a factor if a huge amount of data would need to be held in memory if DataAccess Methods would be used instead of SQL queries. Mostly used by Extracts or Reports.
- \Module\processing subdirectory: contains classes that are called from the PetraServers' Processing functionality (for processing data at certain intervals)
csharp\ICT\Petra\Client\app\ contains code that is necessary for the basic operation of the OpenPetra Client.
The main PetraClient.exe is compiled from a project in
There are the directories
CommonDialogs. They hold C# Classes which are used in many other windows of the OpenPetra Client.
There are directories for each OpenPetra Module, e.g.
MCommon is not a true mapping to an existing OpenPetra Module that the user knows of. It contains code that is used across several OpenPetra modules.
Each OpenPetra Module directory has a subdirectory
Gui which contains *.yaml files. These YAML Files are turned into generated C# Classes with the command
*.ManualCode.cs files are holding C# code for everything that cannot be generated automatically.
This is a tool for connecting to the OpenPetra Server. It is used for shutting down the OpenPetra Server and it allows the OpenPetra Server administrator to check which users are currently logged in, among other things.
At the moment, we have a few plug-ins for authentication against another service, eg. phpBB.
We have for example a plug-in for importing German bank files.