FEATURE: Custom label for auto created child nodes

[dfeyer]

This change add a node type configuration to generate a custom node label for auto created child nodes:

'Neos.Neos.NodeTypes:Page':
  superTypes:
    'Neos.Neos:Document': TRUE
  childNodes:
    main:
      label: 'Main Content Collection'
      type: 'Neos.Neos:ContentCollection'

This allow to have a less technical content tree. This change include the schema validation and default label for default node types.

The label can be a string or an EEL expression. Inside the expression you can access the parent node in the variable parentNode.

[mention-bot]

By analyzing the blame information on this pull request, we identified @radmiraal, @skurfuerst and @aertmann to be potential reviewers

[dfeyer]

Pretty useful for ContentCollection to replace "Content Collection (footer)", by something more human readable like "Document Footer". Also useful with complex node type with multiple child node, like a Staff, with multiple PostalAddress and ContactInformation, ...)

[kitsunet]

See inline comment 👎 for now

[aertmann]

Nice idea, I think we can make it work.. see inline comments

It's missing documentation as well though

[dfeyer]

@aertmann @kitsunet Now support string, and no dependency to the ContentCollection anymore, it's pretty generic and useful.

As discussed with @kitsunet last week, we need to take to not have too much configuration that can depend on the "context" (parent node, ...) or we will have hard time to debug it.

Next step a small documentation and this one is merge ready

[dfeyer]

Up to date with master and update the first PR comment to show the possibility to use a string or EEL expression as label.

[kitsunet]

👍 Shoudl be fine!

[dfeyer]

@aertmann If you can review again we can merge this one

[dfeyer]

@aertmann @kitsunet Maybe this can finaly be merged ;)

[dfeyer]

Thanks @aertmann for the review, all comments fixed

[kitsunet]

I re-read the code and from a user perspective this is great, but I am still not convinced about the implementation. That's a lot of logic in the LabelGenerator that any person implementing the interface would have to replicate. Also The LabelGenerator shouldn't be in charge of figuring this out. If we want to do this, we might want to change the interface to tell the generator where to get the config from maybe.

[dfeyer]

@kitsunet What if we introduce an Abstract class with helper function, and a protected method to override the label for the automaticaly created child nodes ? Like this custom implementation can reuse the abstract class and we avoid changing the interface ?

[dfeyer]

And maybe a missing feature is the support of i18n keywords to have translatable labels ...

[kdambekalns]

This looks really useful, so could you (@dfeyer and @kitsunet) decide on a path forward? Thanks!

[bwaidelich]

I added an issue for this: #2276

PS: Not directly related but I'm convinced that we should move away from using EEL directly in YAML as it's really error prone

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions!

[stale[bot]]

This issue has been automatically closed because it has not had activity for some time. But that does not need to be final. If you find the time to work on it, feel free to open it again. Thanks again for your contributions!