Is your feature request related to a problem? Please describe.
Relations are already quite powerful. This is a suggestion for improvement.
(I’m quite new to AT, so let me know if this is already possible somehow.)
Describe the solution you’d like
When creating a new Relation, user would be able to either pick one of the pre-existing ones (as it is now - Text, Number, Status etc…), or create a new one from scratch (really).
Creating from scratch would allow choosing several properties, such as
- Name (a string with the name for this Relation)
- Type (if it’s a text, number, checkbox, email etc.)
- Array (a boolean- true if this Relation allows just one item, or more than one)
- Validation (if it should run some sort of validation, and which is it)
This would allow a wider variety of Relations, such as an array of strings, a checkbox with multiple states or multiple emails, as requested [here](Multiple Email Relations).
PS: I’m using the term Relations above, but [I wonder if they should be called “Attributes” instead?](Change the name "Relations" to "Attributes")
@qualquertipo In general these are good ideas and good things to be thinking about.
Some of what you’re talking about is already possible. You can create new Relations, give them a name, and a “type” (i.e. data type), such as Text, Email, Single or Multi-select. “Array” would simply be another “type” of Relation, however creation of such a totally new “type of relation” seems likely to be outside the scope of what can be reasonably done within the GUI. I suspect that will be something done more as plugins, and/or code contributions in the future.
I’m not sure about “validation”, that’s an interesting one. I guess you mean e.g. making sure that the contents of an “email” field actually contains @ and a valid domain? Again I suspect that kind of thing would need to be done by a developer, at least someone with some basic coding/scripting knowledge. Although certainly there are example GUIs out there for handling validation rules, so it could be added at some point. Interesting to think about, I just wouldn’t want Anytype to get too “heavy”, with every function having a zillion options.
It makes me think again of the idea of “modes” that I’ve raised and advocated for here:
If Anytype does get this “deep”, where you can create and edit almost anything, anywhere in the system, it might make sense to have a simple and quick way to switch between “editing” and “viewing/using” modes so that functions, tools, interactions, etc. can be better tailored to the needs of each way of working.
Yeah, I agree the GUI needs to stay simple and clean for most users/uses.
Choice of existing Relation types (Email, Text, Status etc.) could be done as it is now.
For those who want to create their Relations from scratch (as I suggested) - for example, a Relation which is an array of 3 Text fields -, then maybe they can do it through the Relation’s Object “page”, which doesn’t seem to be used for much currrently.
That list is only an example, and certainly incomplete… I guess the different parameters available to define a Relation should be properly defined, if this system is to be implemented.
I’ll check it out!
@qualquertipo Yes, more good ideas and thoughts.