[TYPO3-content-rendering] [Typo3-dev] Re: Smart Content Rendering

[JoH]

>> Yes - and the magic word is: "templated wraps" + optionSplit
>> If there was the possibility to select the part(s) that is/are used
>> as a wrap from a template all the possible problems you described
>> above could be solved.
>>
>> For example in a menu you could do something like this:
>>
>> allWrap.fromTemplate = 1
>> allWrap =
>>>
*|NEWROW1||1COL||1COL||LASTCOL||NEWROW2||1COL||1COL||LASTCOL|*|NEWROWLAST||
>>> 1COL||2COL
>>
>> NEWROWX and XCOL could be defined in the template.
>
> AAAAAAHHHHHHHHHHHHHHHHH!!!!!!!!!!!!!!!!!!!!!
>
> Introduce option splits whereever you like, but don't force them upon
> the poor admins as the true TS way of templating.

No force - just a new possibility of doing things that could be introduced
without too much additional PHP code.
You can still do it the Golive-, MTB-, FTB-, whateverTB-way _and_ use this
new feature.

I used optionSplit just as an example how loops and conditions (in this case
based on element-positions and _not_ TS-conditions) could be realised.
I think it's much easier for any admin to write something like this:

HEADER_3_COLUMNS
CONTENT1 || CONTENT2 || CONTENT3
SUBHEADER_2_COLUMNS || NEWSHEADER
CONTENT5 || CONTENT6 || NEWSLIST_XROWS
|*LOOP*|CONTENTA||CONTENTB|*LOOP*|
FOOTER_3_COLUMNS

or maybe even something like this:

subparts.HEADER < HEADER_3_COLUMNS
subparts.CONTENT {
CONTENT1 || CONTENT2 || CONTENT3
SUBHEADER_2_COLUMNS || NEWSHEADER
CONTENT5 || CONTENT6 || NEWSLIST_XROWS
|*LOOP*|CONTENTA||CONTENTB|*LOOP*|
}
subparts.FOOTER < FOOTER_3_COLUMNS

than to create a TV datastructure. Remember we are talking about average
admins here and _not_ TYPO3-, TV- or XML-gurus.
If you don't like the word "optionSplit" call it "improved templating".
The major issue is ease of use and this is something that the TV concept is
still missing from an admins point of view.
It offers easy to use templates for the editors but it takes a lot more time
and knowledge for an admin to create these templates for them.
IMHO the Golive-way + loops and conditions could be a good middle course
between traditional templates and TV.
The challenge is to move the wraps from TS to the template to get a real
separation between layout, configuration and content.

You could solve this at the moment with "nested TEMPLATE elements" but this
is of course no good way to go since the TypoScript setup for this approach
would get a horrible structure and the performance would slow down notedly
due to the extensive use of stdWrap:

temp.content = TEMPLATE
temp.content {
    template = FILE
    template.file = maintemplate.html
    subparts {
        HEADLINE = COA
        HEADLINE {
            outerWrap.cObject = TEMPLATE
            outerWrap.cObject {
                template = FILE
                template.file = maintemplate.html
                workOnSubPart = HEADLINE_WRAP
                marks {
                    WHATEVER = whatever
                }
            }
            10 = TEXT
            10.field = title
        }
        MENU = HMENU
        MENU {
            outerWrap.cObject = TEMPLATE
            outerWrap.cObject {
                template = FILE
                template.file = maintemplate.html
                workOnSubpart = MENU_WRAP
            }
            1 = TMENU
            1 {
                NO {
                    allWrap.cObject = TEMPLATE
                    allWrap.cObject {
                        template = FILE
                        template.file = maintemplate.html
                        workOnSubpart = MENU_ITEM_NO_WRAP
                    }
                }
            }
        }
    }
}

The main advantage of using a concept similar to subparts and marks is the
fact that you can use "speaking structures" to have a better understanding
of the different snippets for admins and layouters.
It doesn't matter if you call it MENU_ITEM_NO_WRAP or
DIV_CONTAINER_FOR_NORMAL_MENUITEMS or just NORMAL_MENUITEMS as long as both
the admin and the layouter are using the same name.
A good example of this principle is CSS which is using classes and ids to
acchieve this. You could even use the same name with different setups for
different purposes just by "cascading" it which means placing it into
another subpart.
While creating NORMAL_MENUITEMS in a LEFT_MENU you could do something else
than with NORMAL_MENUITEMS in a TOP_MENU but still use only one template
file. Putting marks into NORMAL_MENUITEMS could give you additional options
like BEFORE - LINK - AFTER or whatever you can imagine.

> PS: More and more I'm convinced that the backwards compatibility with
> old "content default" is a major block for the developing of anything.
> It demands options and twists for everything, even if we all agree it
> should be deprecated.

Well - I fully agree with you, but it's not up to me to break or remove the
"stay compatible" rule.

Joey

-- 
Wenn man keine Ahnung hat: Einfach mal Fresse halten!
(If you have no clues: simply shut your knob sometimes!)
Dieter Nuhr, German comedian
openBC: http://www.openbc.com/go/invuid/Jo_Hasenau