[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<TYPO3.Neos:Page>/body<TYPO3.TypoScript:Template>/content/main<TYPO3.Neos.NodeTypes:Text>"
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