BUGFIX: #3513 #3441 meta keys "sparse" DataStructure

[mhsdesign]

This is the minefield PR for the range 5.3 - 7.3 (later stuff is fixed)

current state summed up here: https://github.com/neos/neos-development-collection/pull/3568#issuecomment-1140829355

---

fixes: #3513 fixes: #3441 fixes: https://github.com/neos/neos-development-collection/pull/3568 #3576

untypedChildKey with meta key is still now an untypedChildKey!

If a meta key was set on an 'untyped' child of a DataStructure, it was counted as typed and such rendered to null.

Btw, ANY meta key would let a key without object, value etc... count as typed. So this wouldnt work until now:

root = Neos.Fusion:DataStructure {
    untypedKey {
        renderMe = 'please'
        @somethingAnything = "foo"
    }
}

Added tests in relation to untyped child keys of DataStructures

Unsetting typedChildKey === untypedChildKey?

currently thats not working, whether this should work could be discussed, but i think it was meant this way? https://github.com/mhsdesign/neos-development-collection/blob/777d11ff1402e9dd47501bb55c6717b6201dd63d/Neos.Fusion/Tests/Functional/FusionObjects/Fixtures/Fusion/DataStructure.fusion#L146 https://github.com/mhsdesign/neos-development-collection/blob/777d11ff1402e9dd47501bb55c6717b6201dd63d/Neos.Fusion/Tests/Functional/FusionObjects/DataStructureTest.php#L142

Checklist

• [x] Code follows the PSR-2 coding style
• [x] Tests have been created, run and adjusted as needed
• [x] The PR is created against the lowest maintained branch

[mhsdesign]

Looks like some unit tests dont like what i have done ... (since the meta key wont stop the datastructure implementation now from creating nested datastructures ...)

---

i looked at the original pr https://github.com/neos/neos-development-collection/pull/2729 ...

maybe we should fix it like https://github.com/neos/neos-development-collection/pull/2729/files/ff31748ec26922d745a099f39baed7b30e9ef85c#r352892386 As there is really lot of internal stuff exposed.

and this sounds fun too ^^ https://github.com/neos/neos-development-collection/pull/2729#issuecomment-561039907

[mhsdesign]

upmerging this will be fun since there where some changes and new things added to the (yet to fix) DataStructureImplementationTest along the road from 5.3 to 7.3 ...

[mhsdesign]

The currently failing ArrayImplementationTest which will become later the JoinImplementationTest made me realize, since JoinImplementation inherits from DatastructureImplementation it indirectly supports the feature of auto creating datastructures (https://github.com/neos/neos-development-collection/pull/2729)

is this wanted behavior? @mficzel

see: https://fusionpen.punkt.de/fusionpen/3807d45e274219afe23973fd4453f783c9d2eaa6.html

[mficzel]

That is an accident … imho it would make sense for join to assume untyped keys to be join aswell

[mhsdesign]

Hmm i dont think untyped nested Joins make sense ... but when it helps some...

The real problem i see, is that were using inheritance everywhere when building the php implementation... couldnt that better resolved with traits? that way we wont run into such bugs...

[mficzel]

That inheritence mainly happened without much intention. Refactoring to traits would be fine, however i would also like to see a concept of defaultType for untyped nodes in fusion as we now have implemented this independently in different places already (offcourse this could also be a special trait):

Examples i am aware of:

• Neos.Fusion:DataStructure
• Neos.Fusion:Case
• Neos.Fusion.Form. .. MultiStepProcess, SchemaCollection, ActionCollection

[mhsdesign]

btw when you extend the DataStructure in fusion, woudnt it make sense that the nested untyped keys become automatically Your:DataStructure? (via $this->fusionObjectName)

prototype(Your:DataStructure) < prototype(Neos.Fusion: DataStructure)

foo = Your:DataStructure {
    foo {
        hi = 123
    }
}

foo = Your:DataStructure {
    foo = Your:DataStructure {
        hi = 123
    }
}

[mhsdesign]

Thinking more about it i think its cleaner to use $this->fusionObjectName instead of the hardcoded name:

https://github.com/neos/neos-development-collection/blob/78bcf8668e4a79f5e85f7771716ab9f2ee7546c8/Neos.Fusion/Classes/FusionObjects/DataStructureImplementation.php#L42

since technically the fusion object could be named prototype(My.Fusion:DataStructure).@class= "...DataStructureImplementation" and Neos.Fusion:DataStructure could even be not available.

[mhsdesign]

simply checking for the existance of any reversed parser path keys is just wrong. See __meta or even __prototypes (partial override wont work as of now)

the fusion parser/interface should expose a list of parse keys which would identify the path as beeing used with value/object/expression like:

ParserInterface::ASSIGNED_PATH_KEYS

[mhsdesign]

i think the parser should not only expose a list of reserved parse tree keys, but an additional list with keys which would identify, that a path has an object or value etc... or since those keys should better not be too much api - create a method, to identify if a path has an object or value/eel assigned or not...

[mhsdesign]

@kdambekalns thanks for reviewing this ;)

this pr targets only neos 5.3 - 7.3

with 8.0 we have this bugfix/complete cleanup from @mficzel: https://github.com/neos/neos-development-collection/pull/3645

and nothing of this pr should land in the 8.0 branch or interfere with it...

i dont really know how to proceed.

the mentioned pr also took concerning some minor edge details a better road. So if we want to fix this bug for 5.3 - 7.3 i would adjust this pr a bit.

---

if you like we can chat about this and the whole issue sometime ;)

[mhsdesign]

Ill close this as won't fix for 7.3 ;) Too sad since we put a lot of effort into it but the problem is just overly complex and we can be lucky to have it fixed with 8.0!