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.
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.
But have a Look at this:
Global field definition
Blueprint - Parent
Blueprint - Child
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?
Have you used it yet?
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!
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.