Please make Whiteboard/Form/etc just fields, not isolated artefacts

This is what I see as a design mistake in the Fibery ecosystem, which is that currently it still holds on to artefacts like Document, Whiteboard and Form (and more to come?) that are relatively isolated and not a well integrated components like entities or fields.

Other comparable modular fieldable entity based systems (e.g. Drupal) allows these artefacts, often called ‘media’, to just be a field that can be attached to any entity type, and has removed these to be created without entity fields.

The Document artefact can already be removed from the ecosystem since we have the rich text field, which does exactly the same, and better.

I tried to make my spaces work with Document, Whiteboard and Forms, but end up using entities with rich text fields and with whiteboards and forms attached, but there are serious problems with doing that, since these attached items cannot be easily organized, listed and related like normal entities.

For example, in order to work with Whiteboards and mimic the entity behavior, I have to create a new entity type ‘Whiteboard’ and add one whiteboard field to it. If I want to organize Forms like entities, I have to create an entity type Form and attach one Form to each Form entity. Then only each unique form will be mimic entity behavior.

Clearly this is not the way to simplify and make the ecosystem consistent, and it is counterintuitive and needs a lot of workarounds for efficiency. Thus, I hope in a future upgrade of Fibery, all features are fields that can be part of entities, and are not presented as isolated pieces of content.

As a transition solution (to satisfy backward compatibility) it would be good to start with a global option setting to disable Documents, Whiteboards and Forms to exist outside of entities.

I think it is quite common for users to want to create Documents and Whiteboards outside of a database. Imagine you want to write an internal document that explains how to use a space. It might reference/embed various views and entities. I’m not sure why it should be necessary to create an entity which has a ‘document’ field just for this purpose.

Also, I’m not sure what you see as the isue with Forms. They are not data containers, merely a data entry mechanism. Again, I cannot see why they should require being ‘owned’ by an entity.

Perhaps other community members will chip in with their perspectives.

Related: Comment fields and inline comments to be entities with fields (comments database)