The main guiding principal regarding FOCUS is that of “Function before Form”. I think this is a great way of understanding how we work with most of the UI table occurrences in FOCUS.
Here is a picture of the Graph in the FOCUS framework. Note that there are 2 main groups. You can define more groups if you see fit, but for now our 2 groups represented here are ERD (denotes entity relationship diagram), and UI (user interface).
![]()
You will also see that we have 3 letter abbreviations that
prefix each of our tables. There is a legend and it is also color-coded. Once
you understand the approach, feel free to create your own 3 letter
abbreviations.
The legend describes the functional behavior of that 3 letter group. So for example, look at tables that begin with ALX (All Records: Cross Product Relationship). Many of the interface layouts are derived from the context of UIN_FOCUS. If you put a portal on the layout based on ALX_PLUGIN (light blue), then you would see all the records in the PLUGIN table.
Here’s another example:
Let’s look at the FOC_PLUGIN (in green) table occurrence. This relationship is based on GT_ID_FOCUS (in the FOCUS table) = ID (in the PLUGIN table). The GT_ID_FOCUS is a multi-key field, so if a field matches an ID, then we have a ‘focus’ on a specific record. Our keys are not only unique by NIC, RecID, and Timestamp, but also with their own unique 3 letter prefix (within the entire file). If you don’t understand this instantly, don’t worry too much, because it will become clearer as you start using FOCUS.
Comments