Classify whitepaper: Construction of views

Classify whitepaper: Construction of views

Classify dynamically creates data entry objects as needed. To do this, the view has a procedure construct_children in which any child objects must be defined. When the view is first activated, the construct_children message will be send and the child objects will be created.

All child objects are created in one pass. However, the setup of the child objects (initialisation, determination of access rights and so forth) is done only when needed. This means every client requests initialisation of it's children. The child object than determines whether it can defer requesting initialisation of its children or not.
A specific example is the subsystem will only request the zooms to initialize if the subsystem is auto-activated.

ClassMessageDescription
cView Activate Ifnot Inventory: Determine Contents
mActivate_Zoom to Top_SBS
mDetermine_Contents Construct_Children
mUser_Setup
Broadcast Request_Contents
Broadcast Parent_Initialized
cFilebuffer End_Construct_Object If DDO set: mInit_Object
mDetermine_Contents mInitialize_Arrays
mCreate_Dummy_Fields If pSlave_State eq Default: Setup server, find mode, slave mode, index
mInit_Child_Object If Slave: mInit_Object
mInit_Object If Not Inventory: mDetermine_Contents
Set pMain_File Set pData_Dictionary
cBase_Subsystem mDetermine_Contents Forward Send
User setup
Set fill needed
mParent_Initialized Acknowledge presence to view
Broadcast mParent_Initialized
mRequest_Contents Broadcast mRequest_Contents
Deleget mChild_Present
mPrepare_Auto_Activate Set Focus_Mode and pIn_Use_State
mActivate Set pIn_Use_State
Activate main child
cSubsystem mRequest_Contents Forward send
mSet_Dynpress_Locations / mAlign_Dynpress_Sizes mResize
cZoombase Construct_Object Request Server
mRequest_Contents mInit_Object
Delegate mChild_Present
Set location
mInit_Object mPrepare_Auto_Activate
Set Main object of parent
mPrepare_Auto_Activate Set focus mode
mParent_Initialized mSetup_panel
mActivate
cEntry_Zoom mInit_Object Forward Send
Set Dynpress_Locations
Set Size
Set Dynpress_Locations
This leads to the following chain of events:
  • Construct_Children
    Construct object cascades down through the (child) objects.
    • Construct_Object (Subsystem)
      Create the subsystem
      • Construct_Object (Zooms)
        Create the zooms
      • End_Construct_Object (Zooms)
        Creation of the zoom done
        • mSetup_User_Rights (zoom)
          Check for user rights and set the according properties
      • End_Construct_Object (Subsystem)
        Creation of the subsystem done
        • mInit_Object (subsystem)
          Sets up the subsystem providing a data dictionary is already set by setting pMain_File in the construct_Object (typical situation).
          The reason this cannot be done upon setting pMain_File is that this would make the ordering of the properties binding; the reason we check whether pMain_File is set is to allow for the dynamic creation of file buffers without setting the pMain_File.
  • mUser_Setup_For_View
    Set user settings
  • Broadcast mRequest_Contents (to subsystem)
    Provoke some action from the child objects
    • mInit_Object (Subsystem)
    • Broadcast send mRequest_Contents (to zooms)
      Provoke some action from the child objects
      • mInit_Object (zoom)
        If zoom accesable, check if the parent subsystem already has a "main object"; if not, we set it to the current object. This will make sure that the first enterable child object of a subsystem will become the "main" object.
      • mChild_Present
        Tell the parent who we are
      • mClient_Present
        Tell the subsystem who we are (data entry objects only)
  • mPrepare_Auto_Activate

  • Broadcast send mParent_Initialized (to subsystem)
    This is send when all initialisation is done
    • Broadcast send mParent_Initialized (to zooms)
      Make suire the message cascades down to all levels