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

Bastian Waidelich bastian at typo3.org
Wed Nov 20 12:27:31 CET 2013


Hi all,

as you know we're in the beta phase with Neos which means we shouldn't 
introduce large changes if it's not evitable.

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

I have spent some time trying to improve the situation in a backwards 
compatible way and it mostly seems to work out quite nicely (skip to the 
last paragraph if you don't want to read the details).

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>

This is much more explicit and less error prone (because you don't need 
to repeat the property name).

The output of the two would be the same, except for the fact that 
currently Neos adds a unique id attribute to each and every node. This 
could be achieved by adding <div class="typo3-neos-nodetypes-text" 
id="c{node.identifier}"> to the template. But I'd suggest to reduce the 
markup to the essentials and let the user decide (something like a 
unique id attribute could easily be added via a TypoScript processor, too).

I also changed Neos so that it doesn't rely on class attributes but on 
data-neos-* attributes that it adds transparently via a TS processor 
(only in user workspace).
If the template contains a root element (like the div in the above 
example and like it should be the case for most content elements) it 
just adds those attributes to this root element. Otherwise it adds a 
wrapping element (I'm currently testing the browser compatibility for an 
unknown element like "<neos-content-element>" which has no visual 
impact). See [1] for a related issue on forge.


Soo, this all seems to work out quite nicely, but..

To add the magic data-neos-* attributes the backend needs I add a 
processor to the TYPO3.Neos:Template TypoScript definition like:

prototype(TYPO3.Neos:Template) < prototype(TYPO3.TypoScript:Template) {
   # ...
   @process.addNodeMetaData = TYPO3.Neos:NodeMetaData {
     @position = 'end'
   }
}

(naming tbd)

This turns the "<div class="typo3-neos-nodetypes-text">" from above into 
s.th. like:

<div class="typo3-neos-nodetypes-text" data-neos-content-element 
data-neos-node-type="typo3:TYPO3.Neos.NodeTypes:Text" 
data-neos-node-context-path="/sites/neosdemotypo3org/roadmap/main/node506586bc14559 at user-admin" 
data-neos-workspacename="live" 
data-neos-typoscript-path="landingPage&lt;TYPO3.Neos:Page&gt;/body&lt;TYPO3.TypoScript:Template&gt;/content/main&lt;TYPO3.Neos.NodeTypes:Text&gt;" 
data-neos-removed="false" ...>

(in user workspace)

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.

One solution is to unset the processor for those like:

page = Page {
   head {
   stylesheets = Template {
     # ...
     @process.addNodeMetaData >
}

but... eeh..

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?


[1] http://forge.typo3.org/issues/53046

-- 
Bastian Waidelich


More information about the Neos mailing list