This is a Feature Proposal
🎩 Description
The resource abstraction is widely being used around the code, but we don't have any clear contracts to figure out what exactly is a resource.
Some models explicitly defined as resource include:
- Proposals
- Results
- Projects
- Other models always inside features.
We currently have a ResourceManifest present in the FeatureManifest, but it's becoming clear the resource abstraction should be expanded to more models, outside of the Feature umbrella.
Examples of other potential resources might be:
- Participatory processes
- Assemblies
- Initiatives
- Users
I propose a heuristic to determine what can be a resource and what not. A resource should have all these properties:
- Can be linked to other resources (via the admin or potentially other interfaces)
- Changes can be traced
- Its public URL can be generated from anywhere
- Have a mandatory Card representation for different sizes (search results, links)
- Have common properties like
title, description and potentially many others.
For that, I propose that we promote the ResourceManifest to a top-level registry (same as Decidim.feature_manifests or Decidim.participatory_space_manifests) and add more properties:
card: A card representation for that resource. Could potentially use cells.presenter: A Presenter that unifies the properties of that resource and extracts title, description.locator: Receives a block with the resource that constructs a public URL. This is particularly useful and would be used by Decidim::ResourceLocator instead of the current approach, which is basically trying to deduct the URL and doesn't work in many cases.
These needs are shared by @tramuntanal & @agustibr on the search engine, and similar concerns have appeared while discussing the admin log with @mrcasals.
Good news is that we can probably incorporate this gradually without touching the public API surface, providing retro-compatibility with the current APIs, so it's not a stop-the-world breaking change that will create friction everywhere.
That said, the scope of the work to be done is quite big. We should definitely alocate time to work on this before the mess gets bigger.
Thoughts @decidim/developers / @decidim/product ?
📌 Related issues
This is a Feature Proposal
🎩 Description
The
resourceabstraction is widely being used around the code, but we don't have any clear contracts to figure out what exactly is a resource.Some models explicitly defined as
resourceinclude:We currently have a
ResourceManifestpresent in theFeatureManifest, but it's becoming clear theresourceabstraction should be expanded to more models, outside of theFeatureumbrella.Examples of other potential resources might be:
I propose a heuristic to determine what can be a resource and what not. A resource should have all these properties:
title,descriptionand potentially many others.For that, I propose that we promote the
ResourceManifestto a top-level registry (same asDecidim.feature_manifestsorDecidim.participatory_space_manifests) and add more properties:card: Acardrepresentation for that resource. Could potentially usecells.presenter: APresenterthat unifies the properties of that resource and extractstitle,description.locator: Receives a block with the resource that constructs a public URL. This is particularly useful and would be used byDecidim::ResourceLocatorinstead of the current approach, which is basically trying to deduct the URL and doesn't work in many cases.These needs are shared by @tramuntanal & @agustibr on the search engine, and similar concerns have appeared while discussing the admin log with @mrcasals.
Good news is that we can probably incorporate this gradually without touching the public API surface, providing retro-compatibility with the current APIs, so it's not a stop-the-world breaking change that will create friction everywhere.
That said, the scope of the work to be done is quite big. We should definitely alocate time to work on this before the mess gets bigger.
Thoughts @decidim/developers / @decidim/product ?
📌 Related issues