Enhance Recipe Step Metadata Exposure via IDetailedRecipeStepHandler Interface

[MikeAlhayek]

Is your feature request related to a problem?

Yes. I would like to create an AI tool that provides a list of available recipe steps along with their associated properties. For example:

• Recipe Step Name: ContentDefinition
• Recipe Step Type: ContentDefinitionStepModel

Currently, there is no built-in way to retrieve this metadata easily.

Describe the solution you'd like

I propose adding two new properties to the IRecipeStepHandler interface to expose information about available recipe steps and their default properties.

To avoid introducing a breaking change, we could instead create a new interface, such as IDetailedRecipeStepHandler, that extends IRecipeStepHandler and includes the two additional properties. This would make it possible for tools to access rich metadata for each step, enabling scenarios like intelligent recipe authoring or AI-powered assistants.

Alternatively, we can add one function that would return RecipeSchema

[Piedone]

IRecipeStepHandlers are about handling the import part of recipes. If you want to retrieve information about available recipe steps, though, i.e. the export part (what should by and large be a mirror of the import one), there's DeploymentStep, what you'd create for all available steps like this:

https://github.com/OrchardCMS/OrchardCore/blob/97884630a19b14f929a1181368f6df9a9855f4d8/src/OrchardCore.Modules/OrchardCore.Deployment/Controllers/DeploymentPlanController.cs#L180

We could instead extend DeploymentStep with additional properties. This is non-breaking and if I understand correctly, would cover your use case. Then these properties, if set, could be utilized to generate default step thumbnails instead of every step having to add their own thumbnail shape template that's always the same, and what only contains metadata (see e.g. this and this one). We'd thus be able to cut down on a lot of repetitive code.

[MikeAlhayek]

In an ideal setup, every recipe handler would have a corresponding deployment step. The deployment step essentially acts as the “export” for what the recipe “imports.” If we had a shared schema that defined both import and export formats, it would help ensure consistency between services, reduce mistakes, and improve maintainability.

Right now, we don’t enforce the same schema for both import and export, which can lead to problems—such as exporting data in a way that the import process doesn’t understand. One possible solution might be to introduce a service that provides both the recipe step and the deployment step schema. This shared schema could then guide both import and export logic.

I’m not yet sure what the best approach is without digging into the recipe and deployment code. When I have time, I’ll explore the codebase further to see how we might introduce a shared schema between the two.

[Piedone]

A shared schema would be great indeed. I remember that there were (are) cases where the export side was missing.

[gvkries]

Related to #1866

[hishamco]

Thanks @gvkries for referring to the related issue, I played a little bit with JSON schema. IMHO, this will bea much simpler approach to go with

[sebastienros]

During triage we looked into the ConfigurationSchemaAttribute support in Aspire and VS integration using this tag:

    <JsonSchemaSegment Include="$(MSBuildThisFileDirectory)..\..\ConfigurationSchema.json"
                       FilePathPattern="appsettings\..*json" />

This is the way

[github-actions[bot]]

We triaged this issue and set the milestone according to the priority we think is appropriate (see the docs on how we triage and prioritize issues).

This indicates when the core team may start working on it. However, if you'd like to contribute, we'd warmly welcome you to do that anytime. See our guide on contributions here.

[Piedone]

Don't you mean that for https://github.com/OrchardCMS/OrchardCore/issues/1866?

[MikeAlhayek]

The idea to create Schema file for the recipe step and another for the appsettings. So that comment for both

[Piedone]

OK, I see.