[TYPO3-german] TypoScript Einführung nötig?

[Niels Fröhling]

 Hy Martin:
> ich denke Du hast recht, hab jetzt mal Deine Mail als Anmerkung ins wiki
> kopiert.
>   
 Welche wiki? :-) Gibt so viele. Ich hoffe mit korrigierten Grammatik- 
und Rechtschreibfehlern. Spreche nicht mehr so viel Deutsch.
> Allerdings habe ich gerade noch keinen Ansatz, wie das einfach und
> verständlich erklärt werden kann.
>
> Ich denke ein Haupt-Problem ist der, dass wir klar zwischen TypoScript für
> TYPO3 und für Extensions unterscheiden müssen. Denn wie die Extensions
> wirklich funktionieren, wissen wir erst, wenn wir uns den PHP-Code
> angesehen haben.
>   
 Ja, ist so eine Programmierer-Krankheit. Aehm, nun das ist nicht so 
schwierig, weiß nicht ob Du in JS versiert bist, jedenfalls ist das dort 
ungefähr so:

 ++++++++++++++
 - Du hast die Basis-Sprache, die selbst auch nicht viel ohne IO-API macht
 - Innerhalb von JS hast Du verschiedene (aber feste) Document-Typen und 
in denen Namensräume:

   - HTML-dokument
   - XML-Dokument
   - SVG-Dokument

 - Du kannst zwar Daten zwischen den Dokumenten hin-und-her kopieren, 
aber sie überschneiden sich nicht, sind wie Parallel-Universen (Du 
kannst nicht einfach eine XML-Node in ein HTML-Dokument einkopieren).
 ++++++++++++++

 So, nun schreiben wir das für TS um:

 ++++++++++++++
  - Du hast die Basis-Sprache, die selbst auch nicht viel ohne IO-API macht
  - Innerhalb von TS hast Du verschiedene (aber feste) 
Interpretations-Räume:

   - BE-Raum
   - FE-Raum

 - Du kannst keine Daten zwischen den Räumen hin-und-her kopieren, sie 
überschneiden sich nicht, sind Parallel-Universen. Manche Erweiterungen 
Tunneln Konfigurationen im BE-Raum in den FE-Raum, das ist allerdings 
nicht die Regel und Erweiterungs-Abhängig.
  ++++++++++++++

   Grundsätzlich ausgedrückt wird im BE TS dazu benutzt, um die 
Benutzer-Oberfläche umzudefinieren, sowohl vom Kern als auch von 
Erweiterungen, wobei Erweiterungen hier selten eine Schnittstelle zur 
Individualisierung zur Verfügung stellen. Einige Kern-Module erlauben 
die Erweiterung ihrer Ausgabe-Typen (wie sitemap z.B.), was ganz klar 
eine wichtige API ist.
 Das blöde hier ist, das die Trennung zwischen BE und FE hier 
eingerissen wird, da eine Konfiguration im TS-Feld zurück auf das 
TS-Setup reflektiert. Besser wäre es einen dritten Raum zu definieren, 
in denen Konfigurationen vorgenommen werden (gäbe es dieses Raum, müsste 
die RealURL-Konfiguration nicht in einer PHP-Datei liegen z.B.). Sicher 
wird damit die Flexibilität genommen, ein BE-GUI-Element sozusagen 
mitten im Baum umzudefinieren, allerdings ist diese Form des 
mitten-im-baum-umdefinieren aus meiner C++-Sicht eine 
Programmierer-Sünde, und schwer nachzuvollziehen (wo hatte ich nochmal 
'Sitemap +image + abstract (5 entries)' definiert?). Aber das ist ja 
eine andere Geschichte, TS-Templates kann man ja auch überall im Baum 
positionieren.

1. Definition
  1.1 'Objekte'
  1.2 Operatoren
2. API - Standard-Bibliothek (wie STL)
  2.1 stdWrap-'Objekte'
3. Interpretations-Räume (oham, besseres Wort gesucht)
  3.0 BE und FE, Zusammenhänge und Überschneidungen
  3.1 Back-End
    3.1.1 Das TS-Feld
    3.1.2 API - Erweiternde Module
      3.1.2.1 cms
        3.1.2.1.1 SITEMAP-'Objekte'
  3.2 Front-End
    3.2.1 Die TS-Templates
    3.2.2 API - Erweiternde Module
      3.2.2.1 cms
        3.2.2.1.1 PAGE-'Objekte'
      3.2.2.2 RTE
      3.2.2.3 css_styled_content
      3.2.2.4 ...

> Und leider wird da oft garnicht mit TypoScript gearbeitet:/
>   
 Vielleicht aus Protektionismus, sobald Du einen stdWrap einsetzt, kann 
der Benutzer alles mögliche damit machen - und manche Programierer (oder 
auch nicht-Programmierer) wollen nicht so tief darüber nachdenken, was 
die Konsequenzen innerhalb der Erweiterungen sind - oder sie tun es 
nicht, aus anderen bestimmt auch richtigen protektionistischen Gründen.
> danke für den Hinweise,
 Gern geschehen.
   Niels