There is a presentation layer which contains a small group of generic page controllers. Each of these can be called by any number of individual component scripts which identify a unique transaction, task or unit of work.
There is a business layer which contains a separate database table class for each database table used by the application. Each of these is actually a subclass of an abstract table class which contains generic shared code.
There is a data access layer which contains a separate DML object to communicate with a specific database engine.
Although it is possible to use words to describe how these components interact with one another, some people are happier looking at pictures. At the present time the most commonly recognised standard for representing the interaction of different processes is with UML (Unified Modeling Language) diagrams, so I have created a set of UML diagrams to show the workings of some of the transaction types which are identified in Transaction Patterns for Web Applications.
Within these diagrams you will see where each class method (function) is called. The following naming conventions are used:
Public methods do not have any particular prefix.
Private methods are prefixed by '_' (underscore). There are two types:
'_cm_' are defined within the generic table class as abstract (empty) methods. These will do nothing unless they are redefined within an individual database table class in order to contain custom code ('_cm_' is short for '_custom_'). These are also known as hook methods in the Template Method pattern.
The HTTP GET method is used to obtain a version of the form with initial values (usually empty).
The user fills in the data, then transmits the results via the POST method. If there are no errors the data is written to the database, otherwise the form will be displayed with the user's input plus any error messages.
The HTTP GET method will cause the controller to extract the record's primary key from the $_SESSION array, which was put there by the previous transction, read the corresponding record from the database, and display the results to the user. If the record cannot be deleted due to the existence of entries on child tables, a suitable error message will be displayed and the SUBMIT button will be removed.
When the user presses the SUBMIT button the POST method will cause the selected database record to be deleted. If there are any associated records on any child tables these will either be deleted or have their foreign keys nullified, as appropriate.
With this type of transaction there is a single step:
The HTTP GET method will cause the controller to extract the record's primary key from the $_SESSION array, which was put there by the previous transction, read the corresponding record from the database, and display the results to the user.
The HTTP GET method will cause the controller to extract the record's primary key from the $_SESSION array, which was put there by the previous transction, read the corresponding record from the database, and display the results to the user.
When the user presses the SUBMIT button the POST method will cause the user's input to be validated, and if there are no errors the selected database record will be updated.
