Would sharing the result of my struggles to achieve an OOP based CRUD design strategy (through, say, an article) be worthwhile?
After over 200 posts to the Sitepoint site alone, and many hours of technical searches on OOP and CRUD (largely futile), book purchases and blind alleys; I've come up with a strategy that appears to serve as a general template beyond my specific application.
I'd like to share it to save others the struggle I've had -- BUT
1) Since I am no longer in IT (former mainframe programmer/analyst), I have no suitable contacts or criteria to know if it's good or it stinks. Where might I look to get competent feedback (given that it is perhaps too large for a forum post)?
2) If it is worthwhile, where should I publish it to share with an audience that could use it?
I'd start here! See reactions and thoughts and then from there you may want to take it to a blog after your article has been refined
All righty then.
Here's a first draft of a snippet after any introductory comments.
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.]