DOC Document new tab order and form scaffolder changes #549
Conversation
| use SilverStripe\Forms\CheckboxSetField; | ||
| use SilverStripe\Forms\TextField; | ||
| use SilverStripe\Forms\TextareaField; |
There was a problem hiding this comment.
Technically unrelated but these were missing.
| To fully customise your form fields, start with an empty FieldList. | ||
| To define the form fields yourself without using scaffolding, use the `tabsOnly` option in [`DataObject.scaffold_cmsfields_settings`](api:SilverStripe\ORM\DataObject->scaffold_cmsfields_settings). See [scaffolding options](#scaffolding-options) for details. |
There was a problem hiding this comment.
This is a new best practice - it's always best to call the parent method when you can, and now you can.
| > [!TIP] | ||
| > It is good practice to invoke the `updateCMSFields()` extension hook afterward, so that extensions in modules can apply their functionality to your field list. |
There was a problem hiding this comment.
No longer relevant since we're calling the parent method.
| - [Define scaffolded form fields for relations to `DataObject` models](#scaffolded-relation-formfields) | ||
| - [`FormField` scaffolding for `DataObject` models](#scaffolding) |
There was a problem hiding this comment.
Moved the existing form field scaffolding item as a sub-item in a new section, so now there's an overall formfield scaffolding section with both the existing docs and the new docs inside it.
|
|
||
| #### Define scaffolded form fields for relations {#scaffolding-relation-formfields} | ||
|
|
||
| Most `DataObject` classes will rely on some amount of automatic scaffolding of form fields in their `getCMSFields()` implementations. However, it's common for modules to provide a specialised form field which is intended to always be used with a specific `DataObject` class. In those cases, even though you always want to use that form field with that class, you have to copy some boilerplate code from the module's documentation to set it up. |
There was a problem hiding this comment.
The only change to this line (see removal of the same line above) was removing the API link since we're linking to that in the parent heading section instead.
|
|
||
| |option|description| | ||
| |---|---| | ||
| |`tabbed`|Use tabs for the scaffolded fields. All database fields and `has_one` fields will be in a "Root.Main" tab. Fields representing `has_many` and `many_many` relations will either be in "Root.Main" or in "Root.`<relationname>`" tabs.| |
There was a problem hiding this comment.
Fields representing
has_manyandmany_manyrelations will either be in "Root.Main" or in "Root.<relationname>" tabs.
Shouldn't these always be in the "Root.<relationname>" tab? Seems like that's the point of the option?
There was a problem hiding this comment.
The tab they're in is determined by the scaffoldFormFieldForHasMany() and scaffoldFormFieldForManyMany() methods which can opt to not include the fields in their own tabs.
This option allows tabs to be used, but it doesn't force it.
|
|
||
| #### Define scaffolded form fields for relations {#scaffolding-relation-formfields} | ||
|
|
||
| Most `DataObject` classes will rely on some amount of automatic scaffolding of form fields in their `getCMSFields()` implementations. However, it's common for modules to provide a specialised form field which is intended to always be used with a specific `DataObject` class. In those cases, even though you always want to use that form field with that class, you have to copy some boilerplate code from the module's documentation to set it up. |
There was a problem hiding this comment.
Probably worth mentioning that SiteTree subclasses would be auto-scaffolded, I know it's documented elsewhere though it's such a common use case I think it's worth mentioning here so people don't get confused why things aren't not working
There was a problem hiding this comment.
This PR is for CMS 5, where SiteTree formfields are never scaffolded.
SiteTree scaffolding is happening in CMS 6.
|
Added docs for |
GuySartorelli
force-pushed
the
pulls/5/scaffolding-and-taborder
branch
2 times, most recently
from
66fdd7f
to
7290280
Compare
GuySartorelli
force-pushed
the
pulls/5/scaffolding-and-taborder
branch
from
7290280
to
f0dcf5b
Compare
Documentation for:
Issue