This document describes the common philosophy to integrating OOFILE into application frameworks.
The philosophy of GUI integration is based around making life easy for existing programs, as well as new ones. Adding OOFILE to your program should not require a radical reshaping of how it works. Thus, we need to work in with the idioms of each framework.
The first round of GUI integration classes was with zApp. This framework is more sophisticated than others with edit forms - it automates the process of storing data in the edit fields. By inheriting from the standard edit fields, and overriding StoreData(), we had a very simple way of updating the database.
However, this approach is not provided for us in other frameworks. It would be easier to move between frameworks if OOFILE worked very similarly in all cases.
Most importantly, if OOFILE links to edit fields by subclassing, this removes your freedom to subclass for your own reasons.
For the above reasons, it was decided that the general philosophy should be that OOFILE communicates with edit fields via an intermediate dbFieldLink.
This abstraction gives us a lot of flexibility - a dbFieldLink subclass could communicate with a different source of data (eg: a comms link) to update a field.
(c) Copyright A.D. Software 1994-1997 (All Rights Reserved).
Last Updated: 8th March 1997