[TYPO3-content-rendering] let's get classy ;)

[Elmar Hinz]

Torsten Schrade schrieb:
> [1] Is it enough to realise a CRS by using a TypoScript library that is
> preconfigured for the user?
> 
> I think: yes! CRS could be a preconfigured TS-Setup depending on the
> users choice to use lean, normal or rich markup.
> 

That could be the way for code genereted by TS-setup.

> [2] If you say no to question 1, why so and where would you want to hook
> in with a "real" php class and for what reasons?
> 

Is it of importance at all, how the tags are rendered itself?

There are a lot of possibilities: TS-templates, HTML-templates,
template engines, pure php, XSLT, ...  This technics would hook in in
most cases where extensions come into the game. The schemes would be a
guide to common results to produce be the different technics.

> [3] How far reaching will it have to be?
> 
> If we understand a CRS in the sense of question 1, in my opinion this
> would imply the following:
> 
> - user includes static file from extension and chooses CRS type (lean,
> normal, rich)
> - CRS provides a basic, multicolumn html layout (l,n,r)

If we differ this makro layout from the mikrolayout of the content
elements. Multicolumn layout should be a possibility. But if a
designer want's to use another kind of makrolayout (i.e. an
oldfashioned tablebased layout) he should still be able to use CRS for
mikrolayout.

> - CRS provides CONFIG & PAGE setup, some values of which can be set by
> using the good old Constant Editor
> - CRS provides some menu scripts (l,n,r)
> - CRS provides an adapted TS setup for css_styled_content (l,n,r)
> 
> Undestood like this CRS does not cover extensions like tt_news et. all
> 
> [4] What is the relation between CRS and other extensions? How would you
> influence the rendering of any given extension?
> 

I would point out 3 parts:

a) The standard HTML output without Extensions
    => CRS core (lean, normal and rich markup)

b) Common extension elements like resultbrowsers, resultlists, etc.
    => CRS core (lean, normal and rich markup)

c) Specific output of specific extensions like calendar monthes view

    => CRS extensions (only specific markup)

CRS extensions should be the exception, because it is likeley that
they will not be supported in all skins. I can quickly make a skin
"sprintime" for CRS core, but I could not do it for lots of CRS
extensions.


> During my tests I quickly found that the TS-Library is the cornerstone
> of everything and this is what I focused on. And I found that putting a
> nice and classy scheme into the wiki like the TMENU with combined
> odd&even + first&last scheme is one thing, doing it another (e.g.
> sometimes stupid need of using .allWrap cause .wrapItemAndSub has no
> stdWrap)
> 
> Anyway, I'm curious to hear your opinions. And: CRS is not dead! :)
> 
> Cheers, Torsten

Regards

Elmar