Blueprint: `entity` field type that groups other fields

[hdodov]

A while ago I had an idea for prefixed groups. Recently, however, another similar idea popped in my mind.

We can have a cluster field type that is basically just a structure with only one entry. It still has a fields property but exists just to group fields as one entity.

Let's say I have a page with 3 sections that all have similar fields. I can define blueprints/fields/base-section.yml:

type: cluster
fields:
  icon:
    type: files
    multiple: false
  title:
    type: text
  content:
    type: textarea

Then in my blueprints/pages/my-page.yml:

title: My Page
preset: page
fields:
  sec1: fields/test
  sec2: fields/test
  sec3:
    extends: fields/test
    fields:
      newField:
        type: toggle

Although this is very similar to using groups it has the added benefit of namespacing. This means that at the end, my page would have the fields sec1, sec2, and sec3 with icon, title, and content in each.

In the template, I could get the fields like this:

<?php
    $sectionOne = $page->sec1()->fields();
    $sectionTwo = $page->sec2()->fields();
    $sectionThree = $page->sec3()->fields();

    // And then use each section's fields like this:
    echo $sectionOne->icon();
    echo $sectionTwo->title();
    echo $sectionThree->newField();
?>

If fields() is too ambiguous, it can be toCluster() so it follows the same pattern as the pages, files, and structure fields.

---

This basically achieves the same thing as my group prefixing idea, but in a less confusing way. Even if you don't need to have the same fields in multiple places, it would still be nice if you could group them. For example, in my site.yml, I would prefer to have this:

fields:
  footer:
    type: cluster
    fields:
      title:
        type: text
      content:
        type: textarea
      links:
        type: structure
        fields:
          link:
            type: url

Instead of this:

fields:
  footerTitle:
    type: text
  footerContent:
    type: textarea
  footerLinks:
    type: structure
    fields:
      link:
        type: url

Since this would probably be used often, Kirby can introduce some syntactic sugar for clusters:

fields:
  $footer:
    title:
      type: text
    content:
      type: textarea
    links:
      type: structure
      fields:
        link:
          type: url

If a field begins with a $, it is assumed it's a cluster and all properties are its fields.

[lukasbestle]

As discussed on Slack:

---

I get why this could make sense, but it has a few major disadvantages in my opinion:

1. Supporting translation for it is going to be tough as Nico wrote.
2. The performance won't be great – parsing YAML without having to isn't optimal. For structures it makes sense because there is no other way to represent the data than a tree structure, but for simple fields it's more complex than necessary.
3. It's also less robust because of that added complexity and could cause issues if the blueprint structure is modified. Simple "flat" fields are easier to convert between different blueprint settings/field types.

So I think that this isn't something that's very suitable for the core, a plugin would be nice though.

[hdodov]

a plugin would be nice though

Well, I made one. I actually ended up creating it by reusing 95% of the Structure field code.

I can see this field type having it's uses for fields that are logically connected. It can group them in the panel nicely and ensures they will move together in the code as well. For example, if I group a few fields related to a footer, I can pass them to a snippet all at once. I also don't have to worry about prefixing since the fields would be scoped under a single name.

I think this field could be implemented without introducing new source code. The Structure field could even extend this one, which means that the implementation is reduced down to simply restructuring the Structure field a bit. Its Vue component is too large anyways and basically combines two views - a table and an entry Form. If you split those, you could easily implement this Entity field and extend it to a Structure field.

@lukasbestle do you think this issue is worth reopening?

[lukasbestle]

Sure! We can't guarantee if and when we will implement this, but let's keep this open for further discussion.

[luxuryluke]

This reminds me of the fieldset HTML element. But your work has other things in it besides form elements.