TASK: Split basic fusion prototype files and define defaults

[Sebobo]

Splits the Fusion prototypes in Neos.Neos and Neos.Fusion into separate files and adds all available parameters of the PHP implementations also in Fusion. This should make it easier for integrators to understand which options are available for each prototype without reading the their PHP implementation code.

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
• [x] Reviewer - PR Title is brief but complete and starts with FEATURE|TASK|BUGFIX
• [x] Reviewer - The first section explains the change briefly for change-logs
• [x] Reviewer - Breaking Changes are marked with !!! and have upgrade-instructions

[mhsdesign]

NOICE! 🎉

[Benjamin-K]

Very nice. I'd prefer having an example for each of the prototypes, especially for beginners. A beginner could guess what Neos.Fusion:CanRender or Neos.Fusion:Component does, but an example would help a lot, especially if we have it for some of the prototypes.

[mhsdesign]

+1

but we should be carefull about the single source of truth - maybe generate the docs from the sourcecode? https://discuss.neos.io/t/documenting-fusion/6056/4?u=marc

[Sebobo]

I thought about the examples too, but would add them in follow-up PRs, as they are more work and better done in batches maybe.

[mhsdesign]

i agree that can be done later. This IS already a big improvement to have all paths of the object written out ;)

[mhsdesign]

i dont think we should start inline documentation, when this code would not be used for the rendered docs (as thoses two things can easily diverge).

but currently the fusion ast parser ignores any information about the comments - that would need to be changed...

[Benjamin-K]

Then skip for now. We can add a link to the docs later instead of creating full examples inside the fusion files. This already is a big improvement 👍

[mhsdesign]

yes we often had that plan ^^ it was even proposed to remove them directly next release (that would have been neos 5 ^^) https://github.com/neos/neos-development-collection/pull/2189

so i guess its gonna be 9.0 since we missed it with 8.0

[Benjamin-K]

What about a soft removal in 8.3 by only removing the include – so Root.fusion in Neos.Fusion only includes Prototypes/*.fusion? That way, developers can include the Deprecated folder if they still use old prototypes and in 9.0 we can remove them completely? So developers will have kind of a pre-warning that they need to adjust their prototypes.

[mhsdesign]

even if this would be technically breaking - one can easily fix that as you said. i like this better that completely destoying everything with 9.0 (ESCR is already quite breaky ^^)

... but on the other hand if we could provide a good migration (i think we have already one?) then it should be quite easy to adjust the code and should not require a special soft removal?

[Sebobo]

There is a migration and we should target 9.0 for this. I don't see how those few prototypes could be a problem until then.

[mhsdesign]

we missed renderer in https://github.com/neos/neos-development-collection/blob/9c7daf8790096f41496ba244a519f302bddcd388/Neos.Fusion/Resources/Private/Fusion/Prototypes/Matcher.fusion#L5

[Sebobo]

Shame shame shame!

[mhsdesign]

😂😂 noticed it randomly when using your declarations to teach the api of the matcher

too bad i guess fusion will collapse now and burst into fire. Ill fix it once im on my pc ^^

[mhsdesign]

Ups we may have broke the default error handling in 8.2 https://discuss.neos.io/t/redirect-issue-to-404-not-found-page-in-neos-demo-neos-flow-8-2-0/6169/3?u=marc

… needs investigation ;)