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

[Martin Holtz]

Hallo Niels,

>  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.
wiki.typo3.org

>  ++++++++++++++
>   - 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.
>   ++++++++++++++
hm... ok

ich habe absichtlich das Backend ausgelassen. Denn da funktioniert ja
nochmal alles anders.

BE: DB->SeitenTSConfig->Formulare->SeitenTSconfig->DB

FE: DB->TypoScript->HTML

Aber im Frontend kannst Du nicht jede Extension via TypoScript ansprechen.

plugin.tt_news.wrap = hallo|welt
kann nicht funktionieren, wenn "wrap" nicht implementiert ist.

>    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,
Sehe ich nicht so. Du definierst im Backend nur, was wie aus der Datenbank
geholt wird und wieder reingeschrieben wird.

Im TypoScript definierst Du dann, was Du aus der DB holst und wie in z.B.
HTML ausgibst.
IMHO ist das sauber getrennt.

> in denen Konfigurationen vorgenommen werden (gäbe es dieses Raum, müsste
> die RealURL-Konfiguration nicht in einer PHP-Datei liegen z.B.). Sicher
grundsätzlich sollte es möglich sein, dass auch so zu programmieren, dass
das im Backend über Seiten-TS oder so gepflegt würde - nur wäre das sehr
umständlich und aufwändig.

> 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.
jup - und wenn man damit dummes anstellt... ich finde es sehr praktisch, auf
bestimmten Seiten mit z.B. das textpic-Element dramatisch einzuschränken,
so das die Redakteure dort nur das eingeben können, was dort auch
ausgewertet wird.

> 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 ...
hm... ok,
1.1 und 1.2 müsste ich vermutlich nochmal besser erläutern.

2.1 muss meiner Meinung nach deutlich nach hinten, da das sonst abstrakt
bleibt und nicht verwendet werden kann.
3.0/3.1 wollte ich eigentlich (vorerst) nicht behandeln
3.2.1 ist offenbar ziemlich wichtig


>> 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.
ne, es geht nicht um Protektionismus sondern schlicht um Unwissenheit oder
Zeitmangel (ich brauche es nicht, ergo programmiere ich es nicht - was ich
hier nicht verurteilen will, da ich das zu oft selber so mache).
Es gibt meiner Meinung nach einige Extensions, die nicht nötig sind, da das
ganz auch mit TypoScript geht. Aber das ist schwieriger als was mit PHP
zusammen zu hauen (zumindest am Anfang;).

Und deshalb auch mein Versuch mit der TypoScript Einführung - damit mehr
Leute TypoScript nutzen.

gruß & danke für die Hinweise,
martin

-- 
http://wiki.typo3.org/index.php/User:Maholtz/45MinutesTypoScript
TSConfig:
http://typo3.org/documentation/document-library/references/doc_core_tsconfig/current/view/
TSRef: http://wiki.typo3.org/index.php/De:TSref
http://wiki.typo3.org/index.php/User:Maholtz
http://www.martinholtz.de