Added support for snippet manifests#6700
Conversation
| <bindingRedirect oldVersion="0.0.0.0-4.0.0.0" newVersion="4.0.0.0" /> | ||
| </dependentAssembly> | ||
| </dependentAssembly> | ||
| <dependentAssembly> |
There was a problem hiding this comment.
We just removed it, why adding it again?
There was a problem hiding this comment.
Sorry, it got added automatically when adding the YamlDotNet Nuget package. Should I remove it?
|
I don't dislike the idea of Module.md but it looks out of scope for this PR. Doing it only for a project is almost useless as people won't follow continue it. If this is something we want to push it should be at least in the codegen templates. And if there is no actual usage in the admin then it will die by itself. I would favor a new entry in the documentation instead, even a placeholder in the RDT site from @agriffard. |
|
I like the idea of having a separate file triggering the new behavior, keeping the current one otherwise. |
|
Makes sense regarding Module.md, and it is indeed out of scope. I removed it for now, but will update the documentation separately. |
|
Agree with Since we intend to do more with the snippet manifest for Instead I suggest:
Other than that, this is great! I especially love the inclusion of a YAML parser. For |
|
I like Daniel's suggestion of simply naming the manifest |
- Renamed snippet manifest naming convention. - Fields defined in the manifest can now be used as properties on the shape without needing the SnippetField HTML helper.
4 participants
This fixes #6672
The basic idea is that instead of declaring the fields within the snippet template itself, they are declared in a separate file next to the snippet.
This solves some peculiar side-effects, such as the issue described in #6672, and it is a cleaner implementation.
In addition, having a separate manifest allows us to add more information about a snippet, such as a friendly name, description and toolbox icon for example.
This PR retains full backwards compatibility with the way parameterized snippets currently work. Only when you add a .Params.txt manifest file will the snippet element harvester look into it and use that file instead of invoking the HTML helpers within the snippet itself to discover the snippet fields.
I also added a Module.md file as a proposal for allowing module developers to provide documentation alongside their module. We could potentially display these markdown files within the admin somewhere, or even generate online documentation for all modules at some point.