Store Entirety of the Structure Entry

calebgrove commented 7 years ago

Given this blueprint:

staffmembers:
  type: structure
  fields:
    name:
      type: text
    position:
      type: text
employeeofthemonth:
  type: selectastructure
  structurepage: staff
  structurefield: staffmembers
  optionkey: name

This field currently writes this to the content file:

Employeeofthemonth: Gary

But, I would rather have it write it to the file as a single structure entry:

Employeeofthemonth:

-
  name: Gary
  position: Intern

Pros:

As the entire entry is stored, it would make template logic much easier. You no longer need to navigate to the structurepage and filter through the structurefield to pull more data than the optionkey.

Cons:

Because the entire entry is stored, updating the structurefield would result in the Employeeofthemonth becoming outdated. For example, if you changed Gary's position to CEO in the structurefield, Employeeofthemonth would still be left with his position as Intern.

calebgrove commented 7 years ago

If anyone has any opinion on this, I would love to hear it.

samnabi commented 7 years ago

I would recommend storing just the optionkey. The risk of having duplicate & outdated data is not worth the easier logic for me.

calebgrove commented 7 years ago

Agreed. After thinking about this for a little while, I was leaning heavily toward not having the entirety of the field stored. Of course if the optionkey changes in the structurefield, we will have the same problem.

In an ideal world, Kirby AutoID would work with structure fields (https://github.com/helllicht/kirby-autoid/issues/4) and select-a-structure could use the permanent ID to connect the two.

For now, I'm going to close this issue.

calebgrove / select-a-structure

Store Entirety of the Structure Entry #5