Field options vs Global field definitions?

In Kirby 2.3 fieldoptions is a new feature:

I think I understand how it works. It populate fields from for example a parent blueprint. What I don’t understand is a real life example when this could be a better fit than global field definitions.

In global field definitions a field is added globally. Then I can call that field from any blueprint. Then when do I want to use field options instead?

This is not criticism, it’s me who want to see the whole idea behind it. :slight_smile:

Field options has nothing to do with global field definitions.

Field options adds another way of adding options to a select or checkbox field by querying the field of another page.

I know that field options has nothing to do with global field definitions. :slight_smile:

But have a Look at this:

Global field definition

# /site/blueprints/fields/selector.yml
label: Category
type: select
default: architecture
  design: Design
  architecture: Architecture
  photography: Photography
  3d: 3D
  web: Web

Blueprint - Parent

# /site/blueprints/parent.yml
  selector: selector

Blueprint - Child

# /site/blueprints/child.yml
  selector: selector

Both parent and child now uses the same options in a very simple way. As I understand it field options is another way of doing just that?

What I still can’t figure out is in what cases field options would be better? :worried:

Have you used it yet? :slight_smile:

The blueprint options can only be changed by a developer, not by the user. Think about categories a user might add to in the future.

I tried it now for the first time and it’s working fine.

My first attempt that failed was to populate it by a config array as json. I wanted relative url instead of static but that don’t seems to be possible so I gave up on that approach.

Then I tried to figure out some way to have nicer labels instead of using tabs keys as labels but I did not figure that out either.

In conclusion I tried to populate it by code and have nice labels, but I ended with populate it by another field with less nice labels. It’s fine anyway! :slight_smile:

I could populate it by adding the values in the blueprint but I want to separate it from the rest of the blueprint, like a custom part that I could control separatly.

Just wanted to share some thougts now that I’ve tested it.