Had some discussions with Robert about it. Current state:

• We think that three trees are relevant for rendering. First, there is the TYPO3CR Node Tree, which gives us the nodes which we want to render. Second, the TypoScript "Prototype Tree", which is the TypoScript configuration tree. This states things like "in the 3rd column, all images shall have a max width of 500 px". Third, there is the Rendering Tree, which is the instanciated TypoScript Prototype Tree with the TYPO3CR Nodes. This is closely mapped to the resulting page.
• The root of the trees are as follows:
  • In the TYPO3CR Node Tree, we use the nearest TYPO3CR:Folder as the node where the rendering starts
  • We also use this TypoScript configuration for rendering all subnodes.
• the TypoScript instance tree does not need to be buildable, as people could do this directly in the template. It's an edge case we do not need to focus on now.
• The TypoScript configuration needs some way to define prototype inheritance, and collections.
• maybe we can drop the explicit Presentation Model.

Some updates:

We have thought about some concepts and got some impressions from that:

1) CSS Selector syntax will not be enough as we need to be able to define NEW structures via Typoscript.
2) Prototypes for rendering are generally a good idea, we would need a way to override properties of prototypes in subobjects, so you can change the prototype for different concrete contexts of rendering (left/right section for example)
3) we need a way to create a new object from the prototypes via configuration and a way to render specific nodes (for example having a special element that renders the content and a menu of headlines for a page -> we need to render a Menu which is not defined in TYPO3CR + the TYPO3CR content but probably in another place)
4) for collection rendering a CSS like syntax would be nice, to have the ability to influence single node rendering (first node should have headline h1, and every third node should have a <br /> after, something like that - so a nicer syntax for v4 optionSplit-like stuff)

All in all the ideas tend to go in the right direction but the "feel" is not there yet, for know all these parts are too separate and not easy to describe. We need a holistic concept that involves all of the above and with an understandable syntax (second step after defining the overall concept).

• Instance of a TypoScript Prototype
• dynamically built at runtime, not declarable in TypoScript syntax
• not addressable in TypoScript

• Example: "TYPO3.TYPO3:Head", "TYPO3.TYPO3:Body", "TYPO3.TYPO3:Section"
• Blueprints for the runtime TypoScript objects used for rendering
• is not necessarily backed by a PHP class
• implement prototype inheritance: Com.FooBar:Text3 < TYPO3.TYPO3:Text
• with JavaScript semantics (DIFFERENT from v4):
  - Com.FooBar:Text3 < TYPO3.TYPO3:Text
  - TYPO3.TYPO3:Text.property ALSO affects Com.FooBar:Text3 (TODO: Dot Syntax!!)
• every TypoScript Object is responsible for rendering a corresponding TYPO3CR:Node. This node is resolved by a Node Resolving Strategy, for example:
  - getCurrentNode(): "Current" node in the Node Tree (which should be renderer)
  - getByNodePath("...."): Fetch node with this path
  - node(TYPE, PROPERTIES, SUBNODES): Create runtime node
  - null() -- special case of a runtime node

• Answers the question: "I have a TYPO3CR Node, which TypoScript prototype shall I use for rendering this node?" (especially used in TYPO3.TYPO3:Section)
• has much context information available:
  - TYPO3CR Node (of course including context)
  - TypoScript Prototype Hierarchy from the last TYPO3CR:Folder node onwards (example: TYPO3.TYPO3:Page > TYPO3.TYPO3:Body > TYPO3.TYPO3:Section)
• must be exchangeable (Strategy Pattern)
• could implement for example some "CSS Selector like" syntax
• TODO: syntax still remains an open question

• contains all information to unambiguously render a given Node, under a given TypoScript Prototype hierarchy
• Example: /sites/phoenixdemotypo3org/download/sidebar/textuufas?typoScriptPath = TYPO3.TYPO3:Page > TYPO3.TYPO3:Body > TYPO3.TYPO3:Section > TYPO3.TYPO3:Text
  - Path until folder node: /sites/phoenixdemotypo3org/download
  - Path until content element in TYPO3CR: sidebar/textuufas <-- this is returned by "getCurrentNode" in TS Object
  - TypoScript Prototype hierarchy: TYPO3.TYPO3:Page > TYPO3.TYPO3:Body > TYPO3.TYPO3:Section > TYPO3.TYPO3:Text

ROUGH EXAMPLE DEFAULTS FOR PROTOTYPES

TYPO3.TYPO3:Head {
     - node = getCurrentNode()
}
TYPO3.TYPO3:Body {
    - node = getCurrentNode()
    sections {
         left = Section
         main = Section   
    }
}
TYPO3.TYPO3:Page {
     - node = getCurrentNode()
     head = Head (context = this.context)
     body = Body (context = this.context)
}
TYPO3.TYPO3:Section {
    - node = getCurrentNode()
}
TYPO3.TYPO3:Text {
     - template = file(...)
     - node = getCurrentNode()
     headlineLevel = 1   
}

Own Prototypes derived from defaults

Com.FooBar:Text3 < TYPO3.TYPO3:Text {
     - template = file(...)
     - node = nodeWithUuid(...
     headlineLevel = 1   
}
Com.FooBar:StaticText < TYPO3.TYPO3:Text {
    - node = node(TYPO3:Text, foo=bar, baz=bar)
}
Com.FooBar:Page1 < TYPO3.TYPO3:Page
Com.FooBar:Page2 < TYPO3.TYPO3:Page

Some use cases but no code because the syntax is not there, but all use cases are possible with those concepts:

Use Case 1
2 column content rendering
TYPO3CR Node Hierarchy

- Page
  - Section: left
      - Text 1
      - Text N
  - Section: right
      - Text 1
      - Text N

Use case 2:
2 column content rendering with fixed right column content (right column static, same on all pages)
Var. A: Text in TS defined
Var. B: Text in a "global" text node
TYPO3CR Node Hierarchy

- Page
  - Section: main
      - Text 1
      - Text N

Use Case 3
2 column content rendering with right column content derived from left column (structure/index on right side)
TYPO3CR Node Hierarchy

- Page
  - Section: main
      - Text 1
      - Text N

Just a rough idea for the "selector syntax" to target TS objects in a collection:
We could use a syntax similar to the jQuery CSS selector syntax.
Example:

[...]
<node type="TYPO3.TYPO3:Page" nodeName="somepage">
    <properties>
        <title>Some Page</title>
    </properties>
    <node type="TYPO3.TYPO3:Section" nodeName="sidebar">
        <node type="TYPO3.TYPO3:Html" nodeName="text1">
            <properties>
                <source><![CDATA[some text]]></source>
            </properties>
        </node>
    </node>
</node>

#somepage > properties > title

#sidebar node[type="TYPO3.TYPO3:Html"]:first

There are PHP libraries for that (which probably need some adjustments)

TYPO3 v4 Concepts in Relation to TYPO3 Phoenix concepts¶

CONTENT / RECORDS
Find one or multiple nodes depending on current context, AND TRIGGER RENDERING
-> MISSING: Concept to describe "Collection of Nodes" 
-> roughly corresponds to *Node Resolving Strategy*, just without the render triggering

CASE
-> roughly: 'TypoScript Prototype Resolver Strategy
-> CREATES NEW RUNTIME INSTANCES of TypoScript objects

CONTENT_OBJECT_ARRAY (COA) ??
"Collection of TypoScript objects" 

HMENU / TMENU /...
Menu -> Render "Node Structure" 

Content Objects:
FILE / FORM / HTML / TEXT / IMAGE / IMAGERESOURCE / IMAGETEXT / MEDIA / MULTIMEDIA / USER / USER_INT

PAGE / TEMPLATE / FLUIDTEMPLATE
"meta-stuff" 

(EDITPANEL) ??

REGISTER??

Consequences¶

• CONTENT finds nodes
• TYPO3v4 creates TypoScript objects LAZILY (i.e. when rendering); Phoenix does it EAGERLY --> loss of flexibility

foo = CONTENT
foo.resolvingStrategy = childNodes

foo.renderingConfiguration = CASE
foo.renderingConfiguration.[type] = TYPE ## MUST BE MORE INTELLIGENT, merge configuration ....

Content::render($renderingContext) {
    NodeCollection $nodes = $this->findNodesSomehow();
    return $nodes->render($this->renderingConfiguration);
}
 

IDEA: We split TypoScript into a TypoScript PARSER which returns one giant array like in v4, and a TypoScript EVALUATOR which LAZILY turns the array into TypoScript objects and renders them.

* "exports.*" -> *exports.page1 = Page* --> then, "page1" is renderable.

$typoScript = array(
    'page1' => array(
        __tsObjectName => 'TYPO3:Page',
        implementationClassName => ....
        '__tsDefaults' => array(
            'TYPO3:Page' => array(

            )
        )
        'template' => 'pageTemplate.html',
        'sections' => array(
            '__tsDefaults' => array(
                '__tsObjectName' => 'TYPO3:NodeCollection'
        ),
            'main' => array(
                '__tsObjectName' => 'TYPO3:Text'
            )
        )
    )
);

* $typoScriptString depends on current page....
* TypoScriptRuntime $ts = TypoScriptParser::parse($typoScriptString, $context)
* $ts->render('page1');
** $tsArray['page1'] --> what is the TS Object at this point?
** $pageTsObject = new Page($ts, 'page1');
** // $pageTsObject->setXY... # HERE; processors are evaluated
** return $pageTsObject->render();
*** # In Page
*** $variableContainer->add('context', $context);
*** return $fluidTemplate->render();
*** # Durch ViewHelper
*** $sectionNode = $this->getSection($sectionName); --> Get CR node
*** $ts->pushContext($sectionNode);
*** $sectionContent = $ts->render($currentTsPath . '.sections.' . $sectionName);
*** $ts->popContext();
* $ts->renderPath

*TypoScript* --> *RenderTree* // Node / ContextSpecific Config

pageTemplate.html
<html>
<body>
<ts:page.section name="main" />
--oder--
<f:for each="{context.node.sections.main}" as="node">
# Relative by default, prepend "/" for global path
<ts:render path="sections.main" context="{node}" />
</f:for>
</bod>
</html>

Patch set 1 for branch master has been pushed to the review server.
It is available at http://review.typo3.org/9119

Patch set 1 for branch master has been pushed to the review server.
It is available at http://review.typo3.org/9120

Patch set 1 for branch master has been pushed to the review server.
It is available at http://review.typo3.org/9122

Patch set 2 for branch master has been pushed to the review server.
It is available at http://review.typo3.org/9120

Patch set 2 for branch master has been pushed to the review server.
It is available at http://review.typo3.org/9119

Patch set 3 for branch master has been pushed to the review server.
It is available at http://review.typo3.org/9119

Patch set 3 for branch master has been pushed to the review server.
It is available at http://review.typo3.org/9120

Patch set 4 for branch master has been pushed to the review server.
It is available at http://review.typo3.org/9120

Patch set 4 for branch master has been pushed to the review server.
It is available at http://review.typo3.org/9119

Patch set 5 for branch master has been pushed to the review server.
It is available at http://review.typo3.org/9120

Patch set 5 for branch master has been pushed to the review server.
It is available at http://review.typo3.org/9119

Patch set 6 for branch master has been pushed to the review server.
It is available at http://review.typo3.org/9120

Patch set 2 for branch master has been pushed to the review server.
It is available at http://review.typo3.org/9122

Patch set 7 for branch master has been pushed to the review server.
It is available at http://review.typo3.org/9120

Patch set 8 for branch master has been pushed to the review server.
It is available at http://review.typo3.org/9120

Patch set 6 for branch master has been pushed to the review server.
It is available at http://review.typo3.org/9119

Patch set 9 for branch master has been pushed to the review server.
It is available at http://review.typo3.org/9120

Patch set 7 for branch master has been pushed to the review server.
It is available at http://review.typo3.org/9119

Patch set 8 for branch master has been pushed to the review server.
It is available at http://review.typo3.org/9119

Patch set 10 for branch master has been pushed to the review server.
It is available at http://review.typo3.org/9120

Patch set 9 for branch master has been pushed to the review server.
It is available at http://review.typo3.org/9119

Patch set 10 for branch master has been pushed to the review server.
It is available at http://review.typo3.org/9119

Patch set 11 for branch master has been pushed to the review server.
It is available at http://review.typo3.org/9120

Patch set 12 for branch master has been pushed to the review server.
It is available at http://review.typo3.org/9120

Patch set 11 for branch master has been pushed to the review server.
It is available at http://review.typo3.org/9119

Patch set 13 for branch master has been pushed to the review server.
It is available at http://review.typo3.org/9120

Patch set 14 for branch master has been pushed to the review server.
It is available at http://review.typo3.org/9120

Patch set 15 for branch master has been pushed to the review server.
It is available at http://review.typo3.org/9120

Patch set 16 for branch master has been pushed to the review server.
It is available at http://review.typo3.org/9120

Patch set 17 for branch master has been pushed to the review server.
It is available at http://review.typo3.org/9120

Patch set 18 for branch master has been pushed to the review server.
It is available at http://review.typo3.org/9120

Patch set 12 for branch master has been pushed to the review server.
It is available at http://review.typo3.org/9119

Patch set 19 for branch master has been pushed to the review server.
It is available at http://review.typo3.org/9120

Patch set 13 for branch master has been pushed to the review server.
It is available at http://review.typo3.org/9119

Patch set 14 for branch master has been pushed to the review server.
It is available at http://review.typo3.org/9119

Patch set 20 for branch master has been pushed to the review server.
It is available at http://review.typo3.org/9120

Patch set 21 for branch master has been pushed to the review server.
It is available at http://review.typo3.org/9120

Patch set 15 for branch master has been pushed to the review server.
It is available at http://review.typo3.org/9119

Patch set 22 for branch master has been pushed to the review server.
It is available at http://review.typo3.org/9120