[TYPO3-german] TV Typoscript Objecpath TS überschreiben

Stephan Schuler Stephan.Schuler at netlogix.de
Thu Oct 28 17:56:12 CEST 2010


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hallo Jan.


Du hast aktuell vier Arten von Typoscriptquellen:
1 Lokales Typoscript im Setup von Template-Records die im Root-Template via "Include" eingebunden werden ("Include basis template:")
2 Dateibasiertes Typoscript aus Extensions die im Root-Template via "Include" eingebunden werden ("Include static (from extensions):" und "Include static:")
3 Lokales Typoscript im "Setup" des Root-Templates auf der Rootpage
4 Die oben genannten drei auf Nicht-Rootpages.

Als "1.5" könnte man dateibasiertes Typoscript nennen, das wie folgt im Setupbereich eines Template-Records eingebunden ist:
<INCLUDE_TYPOSCRIPT: source="FILE:fileadmin/template.ts">
Da das aber genau so viel zählt wie lokales Typoscript im Setupbereich braucht man darauf wohl nicht näher eingehen.

Für 4 gilt: Verhält sich innerlich wie 1-3 und zählt dann zu 1.


Wenn du auf eine beliebige Seite im Backend siehst ist die Reihenfolge zunächst die genannte, die Priorität demzufolge entgegengesetzt. Davon abweichen lässt sich über "Include static AFTER basedOn" bzw. "Static template files from T3 extensions: Default (...)", beide Optionen finden sich im "Includes"-Tab des Template-Records.
Ich halte davon allerdings nicht allzu viel, da man sowas einerseits gerne übersieht und andererseits der Vorteil überschaubar ist. Immerhin kann man die Reihenfolge nur "entweder/oder" beeinflussen, eine feinere Reihenfolge der vier Include-Typen lässt sich damit immer noch nicht verwirklichen.


Zunächst würde ich, sofern vorhanden, die vierte Gruppe nach Möglichkeit eliminieren. Ab einer gewissen Seitengröße führt ein Wildwuchs unterschiedlicher, seitenspezifischer Template-Records dazu, dass man eigentlich zusammengehörige Parameter (config.index_enable, config.index_externals zum Beispiel, oder config.sys_language_uid, config.locale_all, config.language und config.baseURL) in zig unterschiedlichen Datensätzen suchen muss. Man erleichtert sich einfach das Leben deutlich, wenn alles was zusammen gehört auch zusammen in einem Template-Datensatz liegt und nur per Condition ggf. auf Seiten unterschieden wird.


Als zweiten Schritt lege ich -- Christian hat das schon geschrieben -- grundsätzlich jeweils möglichst funktional zusammengehörige Parameter in einen Template-Datensatz und funktional unabhängige in unterschiedliche. Ein Hauptmenü mit drei Ebenen ist prädestiniert, einen eigenen Datensatz zu bekommen in dem diese drei Ebenen konfiguriert werden. Ein zweites Menü (Utilities zum Beispiel) bekommt einen zweiten Datensat, das "page"-Rendering darf in einem dritten wohnen. Wenn im Fall von Templavoila diverse FCEs aus lib.xyz bedient werden, kann ruhig jedem FCE ein eigener Template-Datensatz spendiert werden.

Wenn sich diejenigen Dinge häufen die ich zwar sprachabhängig konfigurieren muss, die aber nicht über "_LOCAL_LANG" hinterlegt werden können (ein Beispiel dafür wären Buttonbeschriftungen in FCEs, Bildpfade und Alternativtexte für Bannergrafiken, etc) und die Anzahl der Sprachen größer wird (ich betreue Seiten mit fast 20 Sprachen) lege ich gerne ein "lib.languages" an (lib.languages.de, lib.languages.en, lib.languages.it, etc.) das lediglich die sprachabhängigen Elemente enthält, binde das gleich an erster Stelle ein und referenziere anschließend nur noch mittels Condition die jeweilige Sprachvariante. Wenn aufgrund des Seitenumfangs eine größere Anzahl an Attributen in vielen Sprachen vorliegt schadet es sicher nicht, pro Sprache einen eigenen Datensatz anzulegen, in dem dann die jeweilige Sprache beheimatet ist.


In diesem Zusammenhang lege ich sämtliche Includes von dateibasiertem Typoscript (eben dem TS das aus Extensiosn kommt oder anderweitig als "static" bezeichnet wird) die ich verwenden möchte als jeweils einzelnen Template-Datenssatz an und binde in diesem nur das eine "static" Typoscript ein.


Der Übersicht halber kommen diese Datensätze nach Thema gruppiert teilweise in unterschiedliche Sysfolder.


Im letzten Schritt lege ich ein Root-Template an, das setup und constants klärt (cleart wäre richtig, sieht aber dämlich aus, cleared wäre falsch, sieht noch dämlicher aus ...) und selbst ausschließlich nur via "Include basis template" die einzelnen Fragmente aus meinen ausgelagerten Sysfoldern einbindet.


Wenn nun alle Fragmente einheitlich im "Include basis template:" des Root-Templates liegen kann ich die natürlich auch sortieren.
Auf diese Weise bekommt man so ziemlich alle Template-Bestandteile genau zu dem Zeitpunkt geladen den man selbst möchte. So lässt sich dann auch die Ladereihenfolge recht eindeutig exakt an einer Stellen im Roottemplate ablesen.


Der "Setup"-Bereich meines Root-Templates hat bei mir garkeinen Inhalt und auf Template-Records die nicht auf einer Rootpage liegen verzichte ich vollständig (abgesehen natürlich von denen die im Template-Storage-Sysfolder liegen).


Paradebeispiel für das Problem das sich durch ein solches Konstrukt lösen lässt:
Diverse Extensions und eigene Funktionen basieren auf einer JavaScript-Lib. Nachdem viele Entwickler ihr eigene Vorstellung davon haben, wie und an welcher Position die Lib eingebunden wird (page.includeJS, page.headerData.12345, etc.) verzichte ich gerne darauf, das jede Extension tun zu lassen. Im Root-Template "lib.includeJS.jQuery = ..." wäre dann meistens zu spät wenn vorher "lib.includeJS.irgendEineExtension = ..." schon darauf aufsetzt.


Grüße,




Stephan Schuler
Web-Entwickler

Telefon: +49 (911) 539909 - 0
E-Mail: Stephan.Schuler at netlogix.de
Internet: http://media.netlogix.de

- --
netlogix GmbH & Co. KG
IT-Services | IT-Training | Media
Andernacher Straße 53 | 90411 Nürnberg
Telefon: +49 (911) 539909 - 0 | Fax: +49 (911) 539909 - 99
E-Mail: mailto:info at netlogix.de | Internet: http://www.netlogix.de/

netlogix GmbH & Co. KG ist eingetragen am Amtsgericht Nürnberg (HRA 13338)
Persönlich haftende Gesellschafterin: netlogix Verwaltungs GmbH (HRB 20634)
Umsatzsteuer-Identifikationsnummer: DE 233472254
Geschäftsführer: Stefan Buchta, Matthias Schmidt

- -----Ursprüngliche Nachricht-----


Von: typo3-german-bounces at lists.typo3.org [mailto:typo3-german-bounces at lists.typo3.org] Im Auftrag von Ralf-René Schröder
Gesendet: Mittwoch, 27. Oktober 2010 22:04
An: typo3-german at lists.typo3.org
Betreff: [TYPO3-german] Re: Re: Re: TV Typoscript Objecpath TS überschreiben

>> die Reihenfolge der Abarbeitung siehst du sehr gut im Template
>> Analyser, einfach von oben nach unten...
>
> Ja. Hier steht das Main-Template ganz unten. Dennoch: Wie bekommt man
> das nach oben?

gar nicht


- --
Ralf-René Schröder
http://if-20.com  ... YAML templates for TYPO3
______________________________________________
_______________________________________________
TYPO3-german mailing list
TYPO3-german at lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german


-----BEGIN PGP SIGNATURE-----
Version: PGP Universal 3.0.0 (Build 2881)
Charset: Windows-1252

wpUDBQFMyZ0epp0IwsibV8MBCB6BA/992rbT62emLBVyQG/hMq6ecoZUKCSIpBKx
Gybst3HM70LXnxSXmoMq6O4SJNIKmwLXfyc0x+KwsnNcxK9b6JdtrsaKgs36MUgg
zGqLWfejpZ10ez6z/W0NdjljZtlfO+lfYEITJBy0wpze2ouirgC0Cipv2ttEMESe
qkLBSBxL0A==
=AgR3
-----END PGP SIGNATURE-----


More information about the TYPO3-german mailing list