Differences

This shows you the differences between two versions of the page.

--- examples:builder:belongsto_relation [2021/03/28 21:21]
pdsci-admin [Step 6: Add the related field to the parent table]
+++ examples:builder:belongsto_relation [2021/04/11 19:27] (current)
pdsci-admin [The belongsTo relation]
@@ Line 9: / Line 9: @@
   * Required: a //**parent** table// and a //**child** table//
   * Create a model for the child table with list and form
-  * Add a field named: //[childModelName]// **to the parent table**
+  * Add a field named: //[childModelName]_id// **to the parent table**
   * Extend **the parent controller** with relation behaviour
   * Extend **the parent model** with the desired relation definition (//hasOne//)
@@ Line 103: / Line 103: @@
 Unlike the //hasOne// and //hasMany// relation the //**belongsTo**// relation requires to change the **parent table**.\\
 To be exact, in the parent table a field is required to hold the id of the related child record.\\
-By default October assumes the name of this field as merging the name of the reference to the child model trailed by '_id': **[child model reference]_id**. \\
+By default October assumes the name of this field as merging the name of the reference to the child model trailed by '_id': //**[child model reference]_id**//. \\
 In our example the name of this field will be //agegroup_id//
 \\
@@ Line 110: / Line 110: @@
 \\
 \\
-If, because of any reason, the key field in the parent table cannot be named in the pattern of [child model reference]_id the key name has to be defined in the definition of this relation within the parent model (step 5). In our example this could be like:\\
+If, because of any reason, the key field in the parent table cannot be named in the pattern of //[child model reference]_id// the key name has to be defined in the definition of this relation within the parent model (step 5). In our example this could be like:\\
 <sxh php highlight: [5]>
 <?php
@@ Line 126: / Line 126: @@
 \\
 \\
-===== Step : =====
+===== Step 7: Add related fields to form and list =====
+The final step is to add a field to the parent form view, where the related data can be selected and a column to the list view.\\
+\\
+For the form view and the //belongsTo// relation either a //Record finder// widget or a //Relation// widget (which appears as dropdown for a belongsTo relation) can be used. The Record finder gives a more convenient way to select a record, especially if the child table holds a lot of records. If there are only a few to expect in the child table the //Relation// widget is a good choice too.\\
+\\
+Anyhow, if the //Record finder// is the preferred choice, the most important thing to define ist the //List configuration// (see the property box at the right in the picture below). Here a reference to the list view of the child model is required. In the library this is //$/pds/library/models/agegroup/columns.yaml//.\\
+If for some reason the definition of the child list view is not suitable for the //Record finder// - for example if there are too many columns defined that are not of essence for the selection of a related record - another list view can be defined in the child model. For example to hold only the columns needed. Let's call this additional view //columns_finder.yaml//. Then the reference has to be //$/pds/library/models/agegroup/columns_finder.yaml//
+\\
+\\
 {{:examples:builder:belongsto-agegroup.19-modelcompletition3.jpg?direct&960|}}
 \\
 \\