The cascade input type is probably one of the most special ones available in GreenLight. When you need support for 1:n relationships in your form, you either are going to use subforms or cascade inputs.
While using cascade inputs, you load forms of another model embedded into your main form, while the rest is handled by GreenLight (things such as validation of the related model, saving the submodel, handling connection values, etc.). These forms are rendered in tabs, and you have the possibility of adding new records or removing already existing ones connected to your main model.
The 1:n relationships handled by the cascade input type have to be set up properly according to the Laravel specs. GreenLight uses Reliese to generate models, which means, most likely these relationships are already going to be implemented in your models.
Parameter name | Description |
---|---|
model | The 'n' part of the 1:n relationship (class name, either fully qualified or under the GreenLight namespace) |
titleField | Name of the field to use for tab titles (keep in mind that FK values are not handled correctly yet) |
GreenLight has a built-in administration solution for Newsletter subscribers, which if fits your project, can be used instantly without any modification. Just to have a general idea about how it works, the schema of the related tables looks like this:
As the picture shows, any subscriber could have multiple subscriptions. Cascade inputs can handle this relationship in an easy way. First, your related model (NewsletterSubscription) will need a form config defined in GreenLight, to make sure it can be rendered multiple times in your cascade input.
GreenLight's NewsletterSubscription has the following form config in vendor/greenroom/greenlight/src/Resources/forms/newsletter_subscription.yaml:
id:
type: text
name: ID
parameters: { readonly: true }
newsletter_category_id:
type: fk
name: Kategóriák
parameters: { model: NewsletterCategory }
created_at:
type: text
name: Létrehozva
parameters: { disabled: true }
updated_at:
type: text
name: Módosítva
parameters: { disabled: true }
So whenever you want to embed this subform into a cascaded input (for example, in your Newsletter Subscriber admin page), you just have to set the correct "model" parameter, like in vendor/greenroom/greenlight/src/Resources/forms/newsletter_subscriber.yaml:
categories:
type: cascade
name: Kategóriák
parameters: { model: NewsletterSubscription }
As a result, you will have a "subform" in your main form and you will be able to define as many related records in your 1:n relationship as you want.