As a developer of any complex solution, the need to retain a clear picture of how the solution is structured becomes increasingly critical as the size of the solution increases. In attempt to reduce potential confusion and to increase solution comprehension, a developer perspective of the data is often VERY helpful. In order to achieve this, you should use Developer layouts.
Description: A Developer layout is simply a dedicated layout which is used internally within your solution and never shown to end users. It serves as a canonical location for scripting (if needed) and a visual reference for the underlying data in your solution. Often showing fields which may not be shown in your user interface - such as primary/foreign key fields.
Right-click the image and choose to view image in another tab/window for a larger version
Following the standards outlined in Table occurrence naming for developer tables. This best practice suggests you create a correspondingly named layout with the following features. Keep the names the same because a unified structure is easier to follow. (e.g. a table occurence name of @People should be matched with a layout named @People based on that same table occurence.)
A useful script trigger
You CAN assign an OnLayoutEnter trigger for each Developer layout to a script which both enforces table view and sets the window title based on whatever information you'd like to see. This is helpful when multiple developer layouts are showing. Remember, however, to never modify data or disrupt script flow with a script trigger on a developer layout.
Example OnLayoutEnter Developer Layout script
If [ Developer and Left ( Get ( LayoutName ) ; 1 ) = "@" and TriggersAreActive ]
View As [ View as Table ]
Set Window Title [ Current Window ; New Title: Get ( LayoutName ) ]
End If
The Developer function and the TriggersAreActive function limit the execution of the script to only developers when triggers are not programmatically disabled.
Performance hit
Keeping in mind that if you do use a developer layout for any scripted process, such as looping through records, they will perform faster without any connections to them. They will not have access to related data and ANY script trigger will potentially be a performance hit. Only use the above tip if you know none of the rest of the solution is using a developer layout for the purpose of data manipulation!
A Developer layout will need to have certain settings applied. These can be accessed by right-clicking on a column header while in Table view and choosing the Table View > Edit Properties... option. We suggest the following.
When designing a feature or needing to see multiple developer layouts you can always open multiple windows at one time. From the Manage Layouts dialog use either Command (mac) or Control (win) to select multiple layouts, then click the Open button. You can then use the Window > Hide Window (1) menu option to hide your user facing layout. With all other windows remaining being Developer layouts choose from the organization options of (2) Tile Horizontally, Tile Vertically or Cascade Windows.
Table view will respect the order in which fields are presented in Layout Mode. When in Browse Mode, you can right click on any column header and choose the Table View > Reset... option.