BUGFIX: Handle null values in node cache helper

[Sebobo]

This was supported in previous Neos versions and is hard to solve in a clean way in Fusion, so it’s better if the helper deals with it.

Example from neos.io:

    footerContainer = ${q(site).property('footerContentContainer')}

    @cache {
        mode = 'cached'
        entryIdentifier {
            site = ${Neos.Caching.entryIdentifierForNode(site)}
        }
        entryTags {
            footerContainer = ${Neos.Caching.nodeTag(q(site).property('footerContentContainer'))}
            childNodes = ${Neos.Caching.descendantOfTag(q(site).property('footerContentContainer'))}
        }
    }

[dlubitz]

IIRC we did that on purpose to be type safe.

I'm struggling a bit with soften this, but I also see the point. Question is, if we should allow null values on all node parameter in this helper class?

On the other hand, you will not be able to find errors in your cache tag building, when we simply swollow these empty nodes.

[bwaidelich]

IMO it's fine to be less strict in Eel helpers. We already do that in other places

[Sebobo]

@dlubitz I compared the old and new helper, and in the past the contextNode for the other methods was always optional which caused issues for other workspaces etc. when not provided.
In Neos 9 it wouldn't work at all without it. So I would tend to keep them there.

EDIT: But for consistency we should have a single behaviour. I agree.

But also for debugging purposes, neos-debug would of course show the issue, but in general I would prefer some kind of log for these cases like the i18n log, which tells about our mistakes but is not as rude.
If someone has problems, we can tell them to check their Caching_Development.log (or whatever name) and hopefully they then now what's going on.

[kitsunet]

Yep, I suggested this, I am always for having EelHelpers be a bit more forgiving as otherwise stringing them together is hindered.

[Sebobo]

But the open question: should I adjust all methods to the same behaviour in this helper?