Overview

The sample application consists of 2 modules:

  1. Reference components
  2. Vehicle Ordering sample application

There's also a doc folder at this level which contains documentation for the whole application.

General principles

Each module contains a set of the following folders. This structure is a suggestion; there are no requirements in code for this structure.

NameDescription
bin Contains r-code for the module. There could be multiple bin-* folders (bin-gui, bin-tty, etc)
doc Contains documentation pertaining to the module. Specs, UML and DFD diagrams etc
src Contains the source code for the module. Package naming conventions appear here.
temp Temporary files location
data Contains databases, XML documents and other local sources of data. Not all modules have data (particularly the reference components).
cfg Contains configuration files, such as INI and PF files.
tests Contains unit tests for then package. Can potentially be automated

Component re-use

The structure of the sample application is designed so that each component can be used (or reused) in relative isolation. Consumers of the application can thus use just the presentation layer or just the common infrastructure, or some combination of components.

Reference components (OERI)

The reference components are the building blocks used to construct the application. Each reference component contains code which corresponds to one of the OERA's 'blocks', such as the Presentation Layer, Common Infrastructure etc. This facilitates reuse and readability. In addition, there is a support component which contains a library of supporting code that is used throughout the sample application (and can be used in any application).

The reference components' base namespace/package is OpenEdge. This indicates that this is ABL code provided by OpenEdge. Core classes - such as the standard/default Object - belong to the Progress namespace. For example, Progress.Lang.Object.

Support Code

OERI Reference Components

Note
A certain amount of discussion went into the naming of the root package as well as its sub-packages. Root package name options considered included "Support", "Common" and "Shared". "Support" is would be the most likely alternative, since that's the module name.
The comment was made that "[Your] structure is probably too deep if you end up navigating down through empty directories with no siblings to get at the file. [Your] structure is probably too wide if you have one file in each directory.". This will be a guiding principle of package name, and will is likely to be an ongoing discussion point, since the sample application is relatively small and simple, and thus is unlikely to have a very large codebase.

AutoEdge|TheFactory sample application components

The AutoEdge|TheFactory sample application consists of the "actual" screens, entities and processes that comprise the specialised application, and is built on the foundation provided by the OERI/reference components. Whereas the reference components contains generalised code that can be used in any application, this module contains sample application-specific code. The sample application comprises of 2 main processes - building cars and ordering cars - and common, supporting code. The root package for the application is AutoEdge.Factory.

Build

The root package for all build processes is AutoEdge.Factory.Build

Common

The root package for the common, supporting code is AutoEdge.Factory.Common

Order

The root package for the order processes is AutoEdge.Factory.Order

Coding conventions, references

Coding conventions

OO patterns used