Skip to content

Layout Components

There are some default buttons present in every system. These Buttons handle basic functions like saving a resource, redirecting to /create and more. You can modify the behaviour of these buttons for each module by defining custom options in the bakery plan module definition.

Code example:

{
"bakery_resource_module": "module_identifier",
"bakery_resource": {
"buttons": {
"button_key": {
"<option>": "<argument>"
}
}
}
}

The keys are:

  • save for default ‘save’ button in create view
  • update for default ‘save’ button in update/edit view
  • continue for default ‘save and continue’ button in update/edit view
  • delete for default ‘delete’ button in show view
  • edit for default ‘edit’ button in show view
  • create for default ‘create’ button in index view
  • excel for default ‘excel’ button in index view
  • plans for the default subscription plans button in the show view.

All buttons can take the following options:

  • display: Boolean (whether to display the button at all. Default: true)
  • title: String (a custom title for the button. will be prefixed with buttons. for translations)
  • trigger: event_identifier (The event identifier to trigger when the button is clicked. this will change the functionality of the button and not trigger the default actions)
  • style: primary|dashed|danger|link|- (Actually, this is a lie, most buttons don’t support this)

All of these options can be used individually or combined.

A note to trigger: if the button_key is save, update or contiune (the buttons in /edit and /create) the current value of any fields will be sent to the prototype output of the event element.

You can add custom buttons to the Buttonbar that can trigger any webhook. These Buttons will be shown before other webhook buttons that where auto added by workflow elements using show_in_button_bar: true.

These Buttons are defined the same way and in the same place as customising the default buttons, and they support (mostly) the same options.

There are a few quirks to look out for though:

  • Custom Buttons have to use an identifier that is not one of the keys for default buttons defined above!
  • The display option is ignored and does nothing when defined on custom buttons. Set ‘show_in’ to an empty array if you want to hide a button!
  • If the trigger option is not set, the identifier of the button will be used and treated as a webhook identifier
  • If the title option is not set, the identifier of the button will be used as the translation suffix
  • Ifshow_in is not set, the button will show in every view. If it is set, it will respect the common module modes (e.b. “module.show”)
  • Using the icon option with a valid antd icon identifier changes the icon

You can define buttons in lists that will trigger webhooks with the current entity and field / row information of the clicked button. This enables you to get the specific tuple from the list that’s in the row where the corresponding button was pressed.

These Buttons will only show up in module.show.

The Webhook will receive the field & row information in the selector output. It is an object with two keys.

  • fieldIdentifier <String>: Is the identifier of the list from where the button was triggered.
  • rowIndex <String>: Is the index of the row from where the button was triggered.

Code example for a list field:

{
"identifier": "list_field",
"type": "list",
"options": {
"buttons": [
{
"title": "custom_button",
"trigger": "webhook_identifier",
"icon": "api",
"position": 0
}
],
"fields": [
{
...
}
]
}
}

This Code example will create buttons in the first col of the list that will trigger the webhook webhook_identifier. The translation key of the th element will be buttons.custom_button. The button will show the api icon in the list.

Only the trigger key is required. All other keys are optional.

  • if no title is set, the title will be buttons.webhook_identifier.
  • if no icon is set, a default icon will be used. Only valid antd icon identifiers are supported.
  • if no position is set, the button col will be appended as the last col in the list.

  • options.identifier: string
  • options.size: small|-
  • options.align: center|-

  • options.identifier: string uses translation key module.texts.identifier
  • options.text: string fallback if no identifier is set (be aware that this can not be translated)
  • options.has_border: boolean whether the text component itself should have an extra border. Useful when using in combination with show_in and in a col with options.borderless: true

The calendar component shows entities of your modules as events. Its options, event types, recurring events and a complete example are described on the Calendar page.