home *** CD-ROM | disk | FTP | other *** search
/ Celestin Apprentice 4 / Apprentice-Release4.iso / Demos / OOFILE / docs / zapp.txt < prev   
Encoding:
Text File  |  1995-07-10  |  3.4 KB  |  63 lines  |  [TEXT/ttxt]
  1. zApp Integration
  2.  
  3. This document describes the "helper classes" for integrating an OOFILE database with the zApp application framework.
  4.  
  5. PHILOSOPHY
  6. The main philosophy of our gui integration is cooperation. The helper classes for a given framework should make it possible to take a standard application written in that framework, possibly generated by a screen designer, and quickly convert it to work with OOFILE.
  7.  
  8. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  9. SUMMARY OF MAIN ROLES
  10.  
  11. EDIT FIELDS
  12. It is assumed your framework provides editing classes that manage the editing of a piece of information - we are concerned with storage. Each major editing tool that needs to store data is subclassed to override the "get" and "set" methods normally used to map the control to storage (usually a variable). This allows quick renaming of standard controls. If you have your own, you can copy our logic - it's just a mapping onto the appropriate assignment of values to and from a field, as shown in the ooftest1 example.
  13.  
  14. MANAGING EDITING
  15. Few app frameworks inherently support multi-page dialogs. Our mixin despatches to your code for several common operations:
  16. - changing a visible browser selection
  17. - moving between records
  18. - moving between pages
  19.  
  20. DATABASE BROWSERS
  21.  
  22. EMBEDDED EDITING TABLES
  23.  
  24. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  25. DETAILS
  26.  
  27. EDIT FIELDS
  28. - bit here about how use subclassing
  29.  
  30. MANAGING EDITING
  31. - again bit about subclassing to manage multiple page editing
  32.  
  33. Moving between pages:
  34. dbEditMgr mixes in several methods, leavingPage, startPageTransition, completePageTransition & newRecord.
  35.  
  36.  
  37. EMBEDDED TABLES
  38. zApp's table classes have a few limitations (unable to add rows, no controls in cells) so our integration for embedded tables is currently based on FarPoint's Spread/VBX spreadsheet control.
  39.  
  40. Note: there are early classes for zApp integration with listboxes and zTables included in oofzapp.cpp but they are not supported at this time.
  41.  
  42. dbSSTable is the base class for managing the control, from which descends dbSSViewTable. The latter abstract base class is based on a dbView as the interface to the database.
  43.  
  44. dbSSBrowseTable and dbSSEditTable are concrete classes that wrap some common settings
  45.  
  46. DISCUSSION OF BROWSER HERE
  47.  
  48.  
  49. EMBEDDED EDITING TABLES
  50. dbSSEditTable manages these. In many interfaces, a related file will be edited through an embedded table. Thus the entire set of related records will probably be brought in, shown in the table, edited and written out again.
  51.  
  52. SAVING RELATED RECORDS
  53. This is transparent due to the propagation of dbTable::saveRecord, provided modified records are updated by assigning to the fields - giving a set of cached dirty records to write out in one go.
  54.  
  55. ADDING RECORDS
  56. A dbSSEditTable would normally be associated with some buttons or other controls. The event-handling procedures (eg: clickedAddUse) send an addRow message to the table.
  57.  
  58.  
  59. SPREAD/VBX EVENTS
  60. Normally, in zApp, if you don't need events then you use zVBXControl directly. If you want to trap events, subclass zVBXControl and write your own 
  61. virtual long zVBXControl::eventVBX(zVBXEvent *) to parse events. 
  62.  
  63. CSpreadSheet includes virtual methods for us with nice clean parameters, and its own event dispatching. Thus, for our Spread/VBX based browsers, we just need to subclass CSpreadSheet and replace these methods with something that calls our own SSTable.