Story #44921

Decide TypoScript and TYPO3CR Naming

Added by Sebastian Kurfuerst almost 9 years ago. Updated almost 9 years ago.

Should have
Content Rendering
Target version:
Start date:
Due date:
% Done:


Estimated time:
(Total: 0.00 h)


As Site Integrator, I want to use consistent TypoScript and TYPO3CR Content Types.

As part of this, the names of content type schema, and the TypoScript properties should be gone through.

List of TODOs:


Task #44955: decide Node Type Definition namingResolvedSebastian Kurfuerst

Task #42203: To discuss: naming of 'Section' in NeosResolvedRobert Lemke2012-10-20

Task #44928: Decide on TYPO3CR node type namesResolvedSebastian Kurfuerst


Related issues

Related to Base Distribution - Story #44970: Define Neos 1.0 APINewRobert Lemke2013-01-30

Related to TYPO3 Flow Base Distribution - Feature #45164: Define syntax for validation rules in YAMLAcceptedKarsten Dambekalns2013-02-05


Updated by Sebastian Kurfuerst almost 9 years ago

  • Category set to Content Rendering
  • Target version set to Sprint February 2013

Updated by Sebastian Kurfuerst almost 9 years ago

.. TODO: remove <typo3:aloha.* VHs; and also *.notEditable VHs; as they are not needed anymore

.. TODO: introduce PrimaryContentCollection to make hooking into the main content area of a page easier for plugins?

    {namespace ts=\TYPO3\TypoScript\ViewHelpers}
    <div class="menu">
      <ts:renderTypoScript path="parts/menu" />
    <ts:renderTypoScript path="sections/main" />

.. TODO: rename "renderTypoScript" VH to "render" 
.. TODO: should the "renderTypoScript" VH convert the path "." to "/"?

.. TODO: explain the (somewhat arbitrary) distinction between parts and sections.
.. is that even best practice?

In this case, we changed the template paths for *all menus* which do not override
the `templatePath` explicitely. Everytime `prototype(...)` is used, this can be
understood as: "For all objects of type ..., I want to define *something*" 

The only thing to be aware of inside the Fluid templates is the proper wrapping of the whole content
element with the `<neos:contentElement>` ViewHelper, which is needed to make the content element
selectable inside the Neos backend.

.. TODO: we could use a processor instead of <neos:contentElement>. Is that better or not?
.. TODO: processor ordering: maybe we can also use @position syntax here?? Is it consistent with ordering in TypoScript Collections?

.. TODO: naming of the above neos:contentElement viewhelper. ContentElement vs ContentObject (in TYPO3CR Content Type definition) <-- naming

.. TODO: how can we add constraints on what types of contents are allowed inside sections?

.. TODO: shouldn't the "Image" TypoScript object have an additional property "maxWidth" and/or "maxHeight" 
.. such that we can adjust the max width/height inside a given context directly?

.. TODO: is @override final in regard to the naming?


.. TODO: Processors and eel should be able to work together
.. TODO: processor ordering should adhere to @override notation

.. TODO: Eel Standard Library

- fizzle (TODO: check if syntax is final)

(low prio)

.. TODO: check how we can transform one content type into another (f.e. 2col
.. into 3col) What happens with superfluous structure etc then?


Updated by Sebastian Kurfuerst almost 9 years ago

  • Status changed from New to Accepted

Updated by Sebastian Kurfuerst almost 9 years ago

  • Assignee set to Sebastian Kurfuerst

Also available in: Atom PDF