You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We'll add the ability to auto-scaffold field in CMS 5.3. However no native DataObjects will be using it.
Acceptance criteria
Link autoscaffold to LinkField and MultiLinkField
When asset-admin is installed, File autoscaffold to UploadField for has_many and many_many, with multi-upload set to true
SiteTree autoscaffold to TreeDropdownField and TreeMultiDropdownField
ElementalArea HAS_ONE autoscaffolds ElementalAreaField and ElementalAreasExtension is refactored accordingly.
EditableFormField scaffold a custom gridifeld
TaxonomyTerm autoscaffolded to searchabledropownfield and searchablemultidropdownfield
Any other DataObjects that could be sensibly autoscaffolded is updated to auto-scafolled
Any getCMSFields or updateCMSFields methods that manually replaces a FormField with one that could be auto-scaffolded is updated to do so.
maybe all classes that use Hierarchy other than mentioned above autoscaffold to TreeDropdownField and TreeMultiDropdownField
Post-implementation notes
It's not feasible to change the ElementalArea to auto-scaffold in an ElementalAreaField, because the ElementalAreasExtension is still required for it to work as expected (and to exclude it when it should be excluded, and update various state for the field, etc). Auto-scaffolding as ElementalAreaField would just be a bad dev experience.
I opted to not make the various models in silverstripe/userforms scaffoldable because it requires a lot of refactoring for very little benefit. Outside of the models in that module it's unlikely people will be having direct relations to those models in their projects.
I've added autoscaffolding for BlogTag and BlogCategory to match how BlogPost sets them up - however, I can't update BlogPost to take advantage of that just yet. That'll be handled in Scaffold fields for SiteTree silverstripe-cms#2767
PRs
Kitchen sink CI run - note that because there's a fork for framework, we expect to see a failure in recipe-reporting-tools. There's a test in there that cannot pass when a forked framework is used.
We'll add the ability to auto-scaffold field in CMS 5.3. However no native DataObjects will be using it.
Acceptance criteria
Link
autoscaffold toLinkField
andMultiLinkField
asset-admin
is installed,File
autoscaffold toUploadField
for has_many and many_many, with multi-upload set to trueSiteTree
autoscaffold toTreeDropdownField
andTreeMultiDropdownField
ElementalArea
HAS_ONE autoscaffoldsElementalAreaField
andElementalAreasExtension
is refactored accordingly.EditableFormField
scaffold a custom gridifeldgetCMSFields
orupdateCMSFields
methods that manually replaces a FormField with one that could be auto-scaffolded is updated to do so.Hierarchy
other than mentioned above autoscaffold toTreeDropdownField
andTreeMultiDropdownField
Post-implementation notes
ElementalArea
to auto-scaffold in anElementalAreaField
, because theElementalAreasExtension
is still required for it to work as expected (and to exclude it when it should be excluded, and update various state for the field, etc). Auto-scaffolding asElementalAreaField
would just be a bad dev experience.BlogTag
andBlogCategory
to match howBlogPost
sets them up - however, I can't updateBlogPost
to take advantage of that just yet. That'll be handled in Scaffold fields for SiteTree silverstripe-cms#2767PRs
Kitchen sink CI run - note that because there's a fork for framework, we expect to see a failure in recipe-reporting-tools. There's a test in there that cannot pass when a forked framework is used.
The text was updated successfully, but these errors were encountered: