[Neos] RFC: Simplify templates and reduce auto-generated HTML

Aske Ertmann aske at moc.net
Sat Nov 23 13:15:22 CET 2013

Hi Bastian

Thanks for trying to tackle this issue and I agree that it would be best to solve it before releasing 1.0, because if we get it right it could be like this for years to come.
I think this topic is a bit hard to discuss since it touches many different areas, but I'll try to give my thoughts to some of it.

> There are two characteristics of Neos we'd like to improve though before the "masses" get used to. Those are:
> 1. The NodeType templates (aka Content elements) are quite cryptic
> 2. Neos automagically generates a lot of wrapping elements and attributes to the content, even in "live" workspace
The second one has now been taken care of.

> The template of the Text node type before the change:
> {namespace neos=TYPO3\Neos\ViewHelpers}
> <neos:contentElement node="{node}">
> 	<neos:contentElement.editable property="text">{text -> f:format.raw()}</neos:contentElement.editable>
> </neos:contentElement>
> and after:
> {namespace neos=TYPO3\Neos\ViewHelpers}
> <div class="typo3-neos-nodetypes-text">
> 	{neos:contentElement.editable(property: 'text')}
> </div>
Here's a couple of changes, first getting rid of the contentElement view helper and adjusting the contentElement.editable to be able to be used more simple.

I think everybody is +10 about making the editable view helper simpler, so we should just to ahead a do that regardless of the rest.

Regarding getting rid of the contentElement view helper, that's where we need to discuss and make sure it's the right path because it has many implications. E.g. the class is now not automatically generated anymore, is this a good thing or should we try to just make it configurable if desired?

It's the same regarding removing the automatically generated id. This is something I'm in favor of doing because it allows for linking directly to specific content. However I agree that this is something that should be possible to remove if desired. Preferably by on/off so one doesn't have to modify all templates to achieve it. This speaks in favor of doing with a TypoScript processor/configuration.

Then there's the whole automatic finding the first tag and adding attributes to it, which I'm fine with as long as we test it thoroughly. 

> The problem is that *TYPO3.Neos:Template* is too generic.. We use it for menues, stylesheets, page title and what not. And we don't want to add the content-element attributes to those obviously.
> The only other solution I can think of is adding a new base node type for all nodes that should be selectable in user workspace. S.th. like *TYPO3.Neos:ContentElement*.
> The problem: A plugin for example should be a ContentElement but no Template.
> Any suggestions? Or do you think, this change is not worth the great impact at all?

I see the need for a new TypoScript object for node types, because we use TYPO3.Neos:Template for normal TypoScript objects that aren't node types too. We already discussed doing this for the automatically generated node types which Christopher implemented, but there we didn't do it in the end.

Currently there's a difference between just TypoScript objects and TypoScript objects for node types because we're using two separate packages: TYPO3.Neos and TYPO3.Neos.NodeTypes, which makes it possible to use templates without the contentElement view helper in Neos. But for site packages we don't have this distinction so that's not possible and it's also not that obvious. Notice: An example of this is that TYPO3.Neos:Menu is just a TypoScript menu whereas TYPO3.Neos.NodeTypes:Menu is a node type (editable content).

I see a couple of different approaches to solving this:
1) Make it the integrators responsibility to make sure the meta is added for node types
2) Create a TypoScript object for plugins used as editable content (the default plugin node type would use this) and custom plugins can extend that
3) Always add it to plugins extending the plugin TypoScript object so to avoid the wrapping one has to use the @class to insert a plain plugin via TypoScript

I'm mostly in favor of option 2. And I'm pretty sure there are more options, but can't really wrap my head around that right now.

I think the best way forward is to have a hangout with those who have good knowledge about all the areas. This is probably too complicated and long for our usual discussion meeting, so maybe a group of 4-5 could get together in a hangout for an hour and see if we can agree on a solution and propose it to the list. I'd be happy to join in on that next week if possible.

Best regards

More information about the Neos mailing list