[FEAT] Resource Types

[sfmskywalker]

We propose a new feature called Resource Types, which introduces a composable entity framework for defining and managing custom resource types dynamically. This feature is inspired by Orchard Core's Content Types but adapted for Elsa Workflows to allow developers and users to build modular and extensible entities.

What are Resource Types?

A Resource Type is essentially a document composed of Resource Parts, with each Resource Part containing 0 or more Resource Fields. This structure is entirely composable at runtime by the user:

• Resource Type: A named entity that can hold multiple parts and fields.
• Resource Part: A component of the resource, represented by a .NET type that provides specific properties and behaviors.
• Resource Field: Fields attached to a part, also represented by .NET types that define different field types.

Example:
Consider a Workflow resource type composed of several parts: WorkflowDefinitionPart, TitlePart, DescriptionPart, and OwnerPart. Users can dynamically create resource types and attach relevant parts and fields, allowing for full flexibility and extensibility.

{
   "Name": "Workflow",
   "Versioned": true,
   "WorkflowPart":
   {
      "Enabled": "BooleanField"
   },
   "WorkflowDefinitionPart": {},
   "TitlePart": {},
   "DescriptionPart": {}
   "OwnerPart": {}
}

The above is an example of a Resource Type Definition.
With that in place, the user can now create Resources instances of the Workflow resource type that might looks like this:

json
{
"Id": "some-guid-specific-for-this-version",
"ResourceId": "some-logical-guid-for-this-resource-that-is-the-same-across-its-versions",
"Version": 1,
"ResourceType": "Workflow",
"WorkflowPart": { "Enabled": { "Value": true } }
"WorkflowDefinitionPart": { "workflow data created by the designer goes here" },
"TitlePart": { "Title": "Hello World Workflow" },
"DescriptionPart": { "Description": "My very first workflow" }
"OwnerPart": { "UserName": "Alice" }
}

Why do we need Resource Types?

1. Modular & Extensible Architecture: By using composable Resource Parts, the system can flexibly support new entities (e.g., Workflow, Secrets, Agents, Webhooks) without hard-coding them. Developers can extend the system by adding custom parts to existing resource types without inverse dependencies on the core framework.

2. Reusability: Common behaviors can be encapsulated in reusable parts. For example, a "Tags" part can be applied to various entities (Workflows, Secrets) without duplicating code or creating dependencies between core and third-party modules.

3. Automatic Versioning: Each resource will inherently support versioning, eliminating the need to manually copy and paste version-related fields (e.g., Version, IsPublished, IsLatest) across different entity classes. This reduces redundancy and ensures consistency.

4. Dynamic UI Generation: Resource types and their parts can be managed through a UI where the editor dynamically composes itself based on available display drivers. This allows users to define and manage entities visually.

Additional Benefits:

• Extensible Resource Field Types: Developers can create new field types, attach them to parts, and reuse them across multiple entities, fostering modular design patterns.
• Pluggable Architecture: Third-party modules can inject new resource parts into existing types, making the system more flexible and accommodating for different use cases without core modifications.