Is it possible to define the options of a Single-Select Field in one place, and have the definition instantiated/referenced/used in different Types?
Example: I want to define a Single-Select Type for choosing a “Role”, such as:
Content Writer
Web Developer
Project Manger
SEO Specialist
Admin
Sales Manager
Let’s assume I have four different Types in my app that each need one of these Single Select fields with these exact options.
I want to be able to define this field (the options) in one place, and have this definition used (and updated, should I change it in the future) in each one of my four different Types that has this kind of field.
The same question applies for Multi-Selects fields.
It sounds like you would be well-served to create a type for this purpose, and then create many-to-one or many-to-many relations (to simulate single- and multi-select respectively).
Depending on which App(s) the referring types are in, you may or may not want these ‘enums’ to live in a dedicated App of their own.
Note: It’s also worth thinking about permissions for these enum types.
Yeah, I have also wanted something like this. I think it’s quite similar to this previous request by Chris himself
The question I usually ask myself when considering whether to create a new Type is whether there is any actually useful data beyond the name that I would want to store there. Whether there is any actual utility in having a full-on Entity for every option (of course options in multi-select are basically entities already, I think, but still). Anyway, in many cases the answer is no, I just want a common set of options. There are some examples of these solutions from Fibery itself, such as the newer “World” Types, but honestly I think that’s a great example of where a Type can be overly “heavy” as a solution.
The World “App” actually has tons of maybe useful data in it, such as TLD, “region”, etc. But I am willing to bet that most people who want a consistent list of countries to choose from actually do not need 90% of that additional info. It’s sort of just there because, well, it had to be made as a Type to be usable in multiple other Types (because of Fibery limitations, really), so you might as well add a bunch of additional info just in case. But the reality is that for most people a simple list of countries, expressed in a single-select, would probably be fine. Perhaps even preferable. In the case of the currency “App”, at least it is pulling live rate data (I think the country list is updated too, but still), so it seems to have more reason to be an “App” with Types to me.
This actually raises an idea I haven’t necessarily seen discussed yet, which is something like 1: a “data store” (“array”?) type of field or other “object” in Fibery and then 2: the ability to reference data to populate options of a field. This is different than the existing “Lookup from”, although perhaps it could work similarly. The idea is that it’s not pulling the actual, selected value(s) from some other already connected Type/Entity. It’s pulling the data from a Field (or other data store?) and representing it in one of several different ways (perhaps).
Like let’s say you could do this, reference data somewhere from a field, then set the field data type, and the referenced data would be represented differently depending on that. So if it was a Rich Text field, it would just instantiate all the data there in markdown or plain text, I guess. If it were a multi-select, it would show all the options, and allow you to select from them. I’m kind of thinking out loud here, and realizing that it only probably applies to a limited number of field types, which may suggest it’s not a universal enough concept, or perhaps just that it would filter the list of what field types you could select…
Anyway, that idea would address your need and perhaps some others. Like many things in Fibery it might be usable in creative ways. Or at least the idea could be adapted into something that could (the ability to have “data objects” that exist somehow independent of Types might be very useful for sophisticated formulae for example). I’d welcome any thoughts to refine it, it’s definitely raw…
This only works to emulate a “Single Select”.
It doesn’t work for my current need, which is to define a “Multi-Select-like” field for specifying Permission Groups (i.e., where multiple Groups can be selected).
Seems like Rules might already be able approximate this – create a Rule on the data source (i.e., some field somewhere) that triggers when it’s updated, and have the Action recreate (or update) the “translated result” as new entity(ies) in the “output type”, via a Script.
Actually, my original request was more about laziness(!) in that I thought it would be nice to be able to define a workflow once and make it available for multiple types simultaneously, but I can see why what i wrote can be thought of as large set of cases, including this one.
Yeah, i get that. I think i might have even asked in the past if there was a technical reason why a single- or muli-select couldn’t be ‘owned’ by more than one type (and the answer was, yes, there is).
There is actually some discussions internally about ‘global types’ or ‘app-less types’ where there may exist the need for ‘shared’ data.
I don’t think it quite matches what you’re describing (and probably couldn’t be called lightweight) but there are potentially some overlapping use cases.
Thanks for thinking along with me guys, and Chris for your inside view. I know that all this feedback is going into the hopper and the team has to consider many angles, including what people want, and also what is feasible or works within the current back-end design, etc. It may be unlikely that any particular solution an individual user proposes actually becomes the solution that meets X number of various but related needs. So to kind of sum up my sentiment just generally, and I think you and the team already know this, but it’s worth restating:
Fibery is extremely powerful, but the ways to access that power sometimes feel “heavy”, not just in theory, but in practice. I think this is especially so with in the example of Types, and using them just to get certain capabilities like re-usability. You see and feel the “heaviness” in the way they clutter up your workspace, e.g. filtering of Types in general Search (do you really need your Country list in there? Probably not!), or way that Relationships affect your Entity Layouts and no doubt affect performance, and many other respects.
I know many big changes are being worked on and contemplated, the move to “blocks” being most immediate I think. But I hope as well that the team is strongly considering how to meet the needs of functionality in-between existing, simple, non-reusable Fields, and full-blown Types.
Bumping this as its something I am finding myself in need of now.
For my use case we as an agency provide a list of Services, it would really help to have this Services list as a global collection that can be used as options in multi-select fields in various databases.
Almost thinking of creating a script that syncs the options between our databases Services multi-select fields but seems like it would be complicated.
Creating a space/database to use as a global single/multi-select works okay but has several drawbacks and I would consider it more of a workaround.
EDIT: Created a feature request based on this thread:
I agree, but the process of creating “global” single/multi-selects can be made more intuitive and less messy, I also think it would be a relatively easy feature to implement:
I know that all this feedback is going into the hopper and the team has to consider many angles, including what people want, and also what is feasible or works within the current back-end design, etc. It may be unlikely that any particular solution an individual user proposes actually becomes the solution that meets X number of various but related needs. So to kind of sum up my sentiment just generally, and I think you and the team already know this, but it’s worth restating: