Showing references-* relationships on record view

[mike-hogan]

When I view a customer record in detail, I want to see tabs or similar to related records, like bookings and payments etc.

When I click on one of those tabs, I see the related bookings or payments.

And there is a button to add a booking or payment

Doing so will not require me to enter the customer for the booking or payment, because it is implied by the fact that this is happening in the view of this particular customer

[mike-hogan]

I managed to introduce reference properties as an external property type, so now I can configure a reference property, and manage data for such a property. That's because I have created an extension point for property types.

But this goes deeper into the UI. This conditionally adds zero, one or more tabs to an open record view. If I am viewing a customer, and he has references to orders and invoices and bookings, then those three tabs should be shown alongside the customer details tab.

Making it tougher is the fact that the property referring to the customer is in the order model. So when viewing the customer model, I need to search other models for possibly deeply nested properties, with unknown characteristics, and do the right thing.

How does my external property get that level of control of such a deep part of the user interface?

Shifting references from properties to relationships would help here. In fact making relationship types pluggable like property types are might be useful. Then I could register a references-one relationship type, and when a record is at one end of such a reference, the ui would know what to do.

But the issue with that is, where to place the relationship in the data fabric, specifically in terms of the user interface. Thus far each "cell" in the ui is a property, and relationships allow nested models, so relationships are layed out along the vertical axis and properties along the horizontal axis.

[mike-hogan]

https://github.com/jsongraph/json-graph-specification

[mike-hogan]

I have come to the conclusion (for now) that in addition to a model having support for properties, it needs to have built into it a capability to link to records of another model, with a cardinality of either one or many, and also the ability to have inlined models. So fit them seamlessly into the data fabric, they need to be treated in the same way as properties. So I have renamed properties as "slots" and a slot can be a property, a reference to a record of another model, or an inlined model.

At the same time, I renamed relationships as "nested models", to better communicate that this is an inner structural concern, not linkages between models

All of this should make this card easier. It initially felt like I was going back on the goal of making the model user-extensible. But I think "structural" issues around models should be in the core - nested models, references to other models, inlining of models - all should be core. Individual property types can still be registered, and seamlessly stitched together with structural "slots" or cell types

[mike-hogan]

Completed with this mornings merge