As a package developer, I may have a package that provides a grid editor, a dashboard or something similar.
I typically opt not to include grid editors in the package.manifest files of my packages, but instead describe how to add a grid editor in the readme file of the repository of the package instead - eg. as done here:
One of the reasons for doing this is can there can be multiple configurations of a grid editor (based on the config property in the JSON). If I provided one in my package, it may not have the exact configuration as the user needs - and any changes made to the grid editor configuration in the package.manifest file of my package may eventually be overridden if my package is later updated. So the way I see it, it may be an inconvenience for the end user/developer if the grid editor is defined in the package.manifest file of my package.
So to get around this, my proposal is to introduce what I'm calling grid editor templates. My package.manifest file will then define a template for the grid editor instead.
Alone, a template will not really do anything, and developers will have to open my package.manifest file and copy the template to another package.manifest file. This is one of the reasons I released a package for editing package.manifest files:
The package lets you manage all package.manifest files of your Umbraco solution, and as part of this you can add a new grid editor based on one of the templates.
Ideally this would be something that came native with Umbraco, so people won't have to know about my package to utilize the templates of other packages they might install. Having this out of the box in Umbraco would also improve the user experience for developers as they now can edit package.manifest files directly from Umbraco instead of opening the raw JSON file.
With my proposal, a package.manifest file could specify a gridEditorTemplates property as an array consisting of the available templates. Skybrud's link picker could for instance specify the following template:
In the outer object, there is the name, group and icon properties, which define how the template is displayed in the picker from the above screenshot. The view property is optional, and if specified, the template will only be available if that view exists on the disk.
The config property specifies the URL to a view used for editing the configuration of the grid editor configuration - this means that we now can have a UI similar to that of data type prevalues/configurations:
The inner editor object is used for pre populating the various fields in the Add grid editor dialog as shown above.
Similar to grid editors, package.manifest files may also specify other types of objects where a template could be beneficial. For instance a package could also provide a template for a dashboard, so that the developer of an Umbraco site can choose where and how the dashboard will be shown in Umbraco. My own package does not support this yet, so I don't have an example for this at the moment.
Indeed we definitely don't want to have package.manifest files modified by users. Part of why we have package.manifest files is so that packages don't have to modify global config because that leads to a number of problems, especially with upgrades or package uninstalls. For that same reason we don't really want developers having to modify a package's own package.manifest file.
In v8, you can tweak everything at startup including dashboards, sections, trees, etc... and override whatever might exist in package manifest files. This way as a developer you can modify how your own application works without modifying a package's files (which will lead to problems with upgrades, etc...)
Grid editors is an edge case (currently), in that this collection can be modified on startup like the dashboards, etc... Even still, if we did enable this I don't think it solves the problem that you are describing? My understanding of what you mean is that you define a 'template' for an editor in your package.manifest and in the back office we have some new UI where you can add your own grid editor based on templates found in package.manifest files?
Proposal for package.manifest templates
As a package developer, I may have a package that provides a grid editor, a dashboard or something similar.
I typically opt not to include grid editors in the
package.manifestfiles of my packages, but instead describe how to add a grid editor in the readme file of the repository of the package instead - eg. as done here:https://github.com/skybrud/Skybrud.LinkPicker#using-the-grid-editor
One of the reasons for doing this is can there can be multiple configurations of a grid editor (based on the
configproperty in the JSON). If I provided one in my package, it may not have the exact configuration as the user needs - and any changes made to the grid editor configuration in thepackage.manifestfile of my package may eventually be overridden if my package is later updated. So the way I see it, it may be an inconvenience for the end user/developer if the grid editor is defined in thepackage.manifestfile of my package.So to get around this, my proposal is to introduce what I'm calling grid editor templates. My
package.manifestfile will then define a template for the grid editor instead.Alone, a template will not really do anything, and developers will have to open my
package.manifestfile and copy the template to anotherpackage.manifestfile. This is one of the reasons I released a package for editingpackage.manifestfiles:https://github.com/abjerner/Skybrud.Umbraco.PackageManifests
The package lets you manage all
package.manifestfiles of your Umbraco solution, and as part of this you can add a new grid editor based on one of the templates.Ideally this would be something that came native with Umbraco, so people won't have to know about my package to utilize the templates of other packages they might install. Having this out of the box in Umbraco would also improve the user experience for developers as they now can edit
package.manifestfiles directly from Umbraco instead of opening the raw JSON file.With my proposal, a
package.manifestfile could specify agridEditorTemplatesproperty as an array consisting of the available templates. Skybrud's link picker could for instance specify the following template:In the outer object, there is the
name,groupandiconproperties, which define how the template is displayed in the picker from the above screenshot. Theviewproperty is optional, and if specified, the template will only be available if that view exists on the disk.The
configproperty specifies the URL to a view used for editing the configuration of the grid editor configuration - this means that we now can have a UI similar to that of data type prevalues/configurations:The inner
editorobject is used for pre populating the various fields in the Add grid editor dialog as shown above.Similar to grid editors,
package.manifestfiles may also specify other types of objects where a template could be beneficial. For instance a package could also provide a template for a dashboard, so that the developer of an Umbraco site can choose where and how the dashboard will be shown in Umbraco. My own package does not support this yet, so I don't have an example for this at the moment.Indeed we definitely don't want to have package.manifest files modified by users. Part of why we have package.manifest files is so that packages don't have to modify global config because that leads to a number of problems, especially with upgrades or package uninstalls. For that same reason we don't really want developers having to modify a package's own package.manifest file.
In v8, you can tweak everything at startup including dashboards, sections, trees, etc... and override whatever might exist in package manifest files. This way as a developer you can modify how your own application works without modifying a package's files (which will lead to problems with upgrades, etc...)
Grid editors is an edge case (currently), in that this collection can be modified on startup like the dashboards, etc... Even still, if we did enable this I don't think it solves the problem that you are describing? My understanding of what you mean is that you define a 'template' for an editor in your package.manifest and in the back office we have some new UI where you can add your own grid editor based on templates found in package.manifest files?
is working on a reply...