Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
examples:builder:belongsto_relation [2021/03/28 20:08] pdsci-admin [Step 3: Sidemenu] |
examples:builder:belongsto_relation [2021/04/11 19:27] (current) pdsci-admin [The belongsTo relation] |
||
|---|---|---|---|
| Line 9: | Line 9: | ||
| * Required: a // | * Required: a // | ||
| * Create a model for the child table with list and form | * Create a model for the child table with list and form | ||
| - | * Add a field named: // | + | * Add a field named: // |
| * Extend **the parent controller** with relation behaviour | * Extend **the parent controller** with relation behaviour | ||
| * Extend **the parent model** with the desired relation definition (// | * Extend **the parent model** with the desired relation definition (// | ||
| Line 74: | Line 74: | ||
| {{: | {{: | ||
| \\ | \\ | ||
| + | /* {{: | ||
| \\ | \\ | ||
| - | {{:examples:builder:belongsto-agegroup.14-sidemenu5.jpg? | + | ===== Step 5: Define the type of relation ===== |
| + | The type of the needed relation has to be defined - as usual - in the parents model php file. This file has been created by the Builder plugin (see step 2) and located in the plugins models directory. \\ | ||
| + | In the library example this is //** / | ||
| + | \\ | ||
| + | \\ | ||
| + | The code to add the relation to the model is in the example:\\ | ||
| + | <sxh php highlight: [5]> | ||
| + | <?php | ||
| + | ... | ||
| + | |||
| + | public $belongsTo = [ | ||
| + | 'agegroup' => [' | ||
| + | ]; | ||
| + | |||
| + | | ||
| + | </ | ||
| \\ | \\ | ||
| + | Where | ||
| + | * //' | ||
| + | * //' | ||
| \\ | \\ | ||
| - | ===== Step : ===== | ||
| {{: | {{: | ||
| \\ | \\ | ||
| \\ | \\ | ||
| - | ===== Step : ===== | + | ===== Step 6: Add the related field to the parent table ===== |
| + | Unlike the //hasOne// and //hasMany// relation the // | ||
| + | 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 ' | ||
| + | In our example the name of this field will be // | ||
| + | \\ | ||
| + | \\ | ||
| {{: | {{: | ||
| \\ | \\ | ||
| \\ | \\ | ||
| - | ===== Step : ===== | + | If, because of any reason, the key field in the parent table cannot be named in the pattern of //[child model reference]_id// |
| + | <sxh php highlight: [5]> | ||
| + | <?php | ||
| + | ... | ||
| + | |||
| + | public $belongsTo = [ | ||
| + | ' | ||
| + | ' | ||
| + | ]; | ||
| + | |||
| + | ... | ||
| + | </ | ||
| + | \\ | ||
| + | In this case the field in the parent table has to be named // | ||
| + | \\ | ||
| + | \\ | ||
| + | ===== 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 // | ||
| + | \\ | ||
| + | Anyhow, if the //Record finder// is the preferred choice, the most important thing to define ist the //List configuration// | ||
| + | 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 // | ||
| + | \\ | ||
| + | \\ | ||
| {{: | {{: | ||
| \\ | \\ | ||
| \\ | \\ | ||