FEATURE: Add fusion-prototypes Component, Editable, ContentComponent and Augmenter

[jonnitto]

The prototypes Component, Editable, ContentComponent and Augmenter are transfered from the package PackageFactory.AtomicFusion (https://github.com/PackageFactory/atomic-fusion) into the Neos-core.

• Neos.Fusion:Component: Create a component that adds all properties to the props context and afterward evaluates the renderer.
• Neos.Neos:Editable: Create an editable tag for a property. In the frontend, only the content of the property gets rendered.
• Neos.Neos:ContentComponent: Base type to render component based content nodes, extends Neos.Fusion:Component
• Neos.Fusion:Augmenter: Add html-attributes to renderer code as processor or as a standalone prototype.

In addition the class \Neos\Neos\Service\HtmlAugmenter was moved to \Neos\Fusion\Service\HtmlAugmenter with a deprecated backwards compatible layer.

[mficzel]

Looks good by reading

[aertmann]

this should be Neos\\Neos and should have been caught in a test.. make sure not to test this with the Atomic.Fusion package installed..

[jonnitto]

Fixed

[aertmann]

no need for two empty lines

[jonnitto]

Solved

[aertmann]

What about h1 or p editables? This abstraction is limiting. To override you have to change renderer.editable.renderer.tagName which is pretty cumbersome. Instead maybe get rid of the abstraction and just accept tagName here.

[mficzel]

@aertmann this is a design decision. By not allowing to control the tagName of the editable the rendering component has to take care of the meaningful markup. That way those components can perform well with editables passed or with data fetched vie flowQuery.

[aertmann]

That makes sense, but does that justify the limitation? With Aloha editables like h1 and p behave differently as they don't allow any child tags inside them, however you can remove the h1 tag if it's rendered inside a div or span tag. This is useful when a property should be restricted to a specific wrapping tag. Thus not supporting this in an easy way is favoring being able to render editables without wrapping tags over being able to use text only editables. This is because with the view helper, there will always be a tag around the editable and to remove it you have to do conditional stuff to only use the editable view helper in editing mode.

Maybe there's a way to support the help users achieving both?

[mficzel]

I personally think that this should be part of the editor-configuration and avoid editors behaving different if placed inside a specific tag. In the data is stored in a property of the node and might be rendered in different places.

[aertmann]

I agree, however that's not how it is currently. I can't speak for the new UI though, maybe someone knows if how you achieve text only editables of a specific tag and if it's different from how Aloha works.

[mficzel]

@aertmann i discussed that with @grebaldi and we came to the conclusion that aloha and the ck-editor in the new ui both make a distinction between block and inline containers. This can be achieved with the current component interface already. We think we are fine here.

[aertmann]

@mficzel okay thanks for checking up, guess you could argue that using a inline editable inside a h1 tag would do the trick, although not a easy as just setting the tag to h1

x

[mficzel]

Looking good by reading and testing

[jonnitto]

@mficzel, thank you for your changes. It is looking good by reading and testing.

[grebaldi]

Looks fine (by reading)