All righty then.
Here’s a first draft of a snippet after any introductory comments.
Overall Structure
The idea is that the CRUD activity results from interaction with the user through sending and processing of forms sent to a computer screen. Under this condition, I found that an effective OOP-CRUD structure need exploit only the Inheritance and Encapsulation components of Object Orientation.
The abstract template components of the client pseudo-conversation encapsulates –
- The “Form Abstract”: a component for formatting, populating and sending a form to the client,
- The “ParseForm Abstract”: a component for receiving, parsing and taking appropriate action on the client’s response and
- The “DataManager Abstract”: instantiated by the above components to handle the specific CRUD syntax in the language that the data store requires.
The Form Abstract
The form abstract delegates only the capture of the data the form requires (call this Abstract Function Capture) and the preparation of a child page’s unique content (call this Abstract Function BuildContent).
So what’s left? Quite a lot, actually. The abstract is more code intensive than any of it children. Which is, I believe, vindication of its role. There’s the general layout of the form that includes the heading, any navigation menus or ribbons, meta-data, and any stylesheets and scripts that support them. There needs to be a means to handle messaging and there is also the opportunity for generic functions that the inheriting forms can use.
Without getting ahead of ourselves, perhaps a technical specification of the Form Abstract is in order.
Upon instantiation, the Form Abstract must –
- (To assure proper base addresses to dynamically build file paths) establish whether the application is running in test mode on a local environment or in production mode on the host.
- Build a header as a variable that contains an icon path, the general application title and an optional subtitle.
- Capture any unique data required from the instantiated child by invoking abstract function named “Capture”.
- Grab the child’s unique content as a variable from the instantiated child by invoking an abstract function named “BuildContent”.
- Format any messages in a variable by invoking a local function named FormatMessages which takes an array as an argument. This local function renders that array in the display language (such as xhtml).
- Send the form to the client by invoking a local function named “Show”which, in addition to the fixed format, allows substitution of the above variables.
In addition, for the convenience of the children, create a local, inheritable function that will render a simple array into a drop down list of the display language. It takes two arguments: the array containing the entries in the drop down list, and an optional field containing the item in the list to pre-select.
What’s left for the children?
So the children that inherit form this Form Abstract concentrate solely on what data they need to acquire (Function Capture) and formatting it into the display language (Function BuildContent).
[To digress, there are those who legitimately choose to make the Capture and BuildContent functions as an OOP interface to be implemented rather than, as here, inherited.]
