Coghead master-detail. The matter of choice.

Coghead has two ways of master-detail form organization: local grid and linked grid. I contacted Coghead support guys to find out which way is better for master-detail organization. So, I am going to follow the recommendations and test both variants.

This is what Jonathan McKibbin suggested on local grid:

"Local Grids allow you to add something similar to 'sub records' to a single record. These individual sub records are only displayable in the form of the record that they belong to.

An example on how to create a calculated field which sums the column of a local grid can be found in Tutorial 3: Section 3.

The advantage of this approach is that you can easily add, edit or remove rows from the local grid. The disadvantage is that it is more difficult to report on the local grid and you would need to create calculated summation fields and use those fields in the collection tab's view."

The explanation is really thorough so I created an Invoice using local grid and this is how it looks like:


I easily created a calculated Total field for each item row and calculated summary field Grand Total. In general editing works quite well and the program calculates everything on the fly, but I think the local grid is better to use in case you need to save several one-type objects within the record, without further processing, such as many addresses of the company or several phone numbers. If you need to build any reports based on this data in the future I think the access to the detail only through calculated summation fields is obviously insufficient.

As far as I am through with local grid, let’s take a look how linked grid functions.

Jonathan offered to apply the following with a detailed explanation:

"Linked Grids allow you to display a list of records from another collection. One of the most common use cases is to display related records in a parent-child relationship between two collections. Since the child records are in a different collection this would give you more control over reporting through both views in the child collection or through additional linked grids in other collections.

An example of how to create the parent-child type relationship between collections can be found in Tutorial 2.

The advantage to this approach is that it gives you greater flexibility when it comes to reporting. You can create views within the Items collection or use record tabs to create a dashboard-like interface for reporting. The disadvantage to this approach is that it is a bit more difficult to set up and that you would have to navigate to the Items collection, by clicking on the row of the linked grid in the Invoice record, in order to edit or delete the row."

This is an Invoice if use linked Grid:


Despite the fact its’ structure looks so much alike to the local grid (except for the opportunity to add Items at once), frankly, it was not so easy to create a parent-child relation.

The very process of Invoice and Item table creation was not difficult, but my next steps of relation creation were not that simple:

1. I used Link widget for Item edit form to make it possible to refer to a particular Invoice.


2. Default grid widget displays all Items to Invoice edit form, so I had to set an additional filter to enable the Item selection of a specific invoice.


3. To create Items from selected Invoice and have them automatically linked one should create Custom Action.

Conclusions:

Its nice to have two different mechanisms for master-detail organization, but none of them is an ideal way of implementation.

Local grid is a way too primitive for anything but just gives the opportunity to the customer to enter a variable number of attributes (phone numbers, for example) and Linked grid along with custom action allowed me to tune everything I actually needed, I had such an impression I used a sledge-hammer to crack nuts though.