I am trying to understand the best way to show related entity attributes for a selected entity in the same screen.
Lets say I have Customer and Order entities, and I want one screen with a list of customers in one table, and a separate table listing relevant orders when I select a Customer in the first one.
However I thought that creating a new view for the Customer entity with box checked for the Order attribute (using _local view for this attribute) would do that automatically - but this does not seem to work. What is the point of creating a new view with _local view for related attributes then?
In the getting started guide, a query is used to restrict Orders relevant to selected Customer. Can this be done without specifying a query if a “Nested Datasource” is used? I thought that this was what the nested datasource was for.
Not sure that video answers your questions, so let me explain something.
You have two options when implementing master-detail relationships in screens.
The first option is to use “deep” views and nested datasources. You define a view for the master entity and include the detail entity attribute with local or another view (which can, in turn, include a second level of details). In the screen, you define the corresponding hierarchy of nested datasources. As a result, when the screen opens, it loads all related entities at once and populates the datasources. This is optimal when you display a single master entity. But when you need to display many instances of the master entity in a table, this causes loading of all details of all masters with a massive batch operation. This is usually less optimal then loading details lazily - only for the currently selected master.
So for your case with two dependent tables, better use two non-nested collection datasources with the relationship through a datasource parameter, as explained in the Quick Start guide. So when the screen opens, it will load all masters, but details only for the first master. When the user selects another master, the details datasource will refresh and load details for it.
Hi Konstantin
Thanks for the detail explanation and it helped me.
Just to confirm my understand, use Query to show the detail entity (Composition) to have a better performance, right? Is there any specific case when I must use nested datasource?
Nested datasources are the same (or even better) as separate datasources in terms of performance when you work with a single master entity. This is usually the case for editor screens. Moreover, only with nested datasources you can implement composition editing: Editing Composite Entities - CUBA Platform. Developer’s Manual
But when you need to show a read-only collection of master entities, better use separate datasource linked with a query parameter or through a datasource listener. It will save you from loading extra data from the database.
