Hallo!
Wie organisiert Ihr Euren Code, um den Überblick zu behalten?
Ich hab mehrere Varianten ausprobiert und teile zurzeit wie folgt:
content
- Inhalt-Marker
- lib.stdheader (Header der Content-Elemente)
navis
- Menü(-s)
exts
- Extensions
config
- page
- page.10...
- page.headerData...
- lib.parseFunc... (parsing rules )
meta
- config.headerComment...
- "Supermeta" (config.xmlprologue, .metaCharset, .language etc.)
- HTML-Metas (page.meta.language, .meta.author, .meta.robots etc.)
- page.headerData. (Seiten-Titel)
Aber das ist keine schöne Aufteilung -- inkonsequent und inkonsistent -- gefällt mir nicht. Sie ist mehr oder weniger spontan entstanden, es steht kein Konzept dahinter...
Wie splittet Ihr Euer TS? Nach TLOs (config, plugin, tt_content, page)? Oder noch irgendwie?
Danke.
main: PAGE, und zuweisung aller subparts an marker
+ext subparts: alle subparts
+ext config: ganze was unter config ist
+ext ext: alle extensions, wenns mehr als 150zeilen sind dann extra
+ext ce: content elemente per ts
+ext sonstiges ts: tt_content usw
georg
just2b schrieb
+ext ce: content elemente per ts
Was meinst Du mit Content-Elementen per TS?
Warum teilst Du das TS so auf und nicht anders?
ich erstell oft content elemente per TS, da ist das dann drinnen.
warum so? hat sich als bewährt empfunden und sagt mir meine erfahrung
georg
CE per TS. Also so was:
page = PAGE
page.10 = TEXT
page.10.value = HELLO WORLD!
?
OK, verstehe.
Und wo definierst Du die Parsing-Regeln (lib.parseFunc.)?
brauch ich eigentlich nie, aber wenns mehr wäre in nem eigenem TS... das ist die struktur von meinen TS, nicht der Weisheit letzter Schluss! 😉
georg
Bin jetzt dabei, meine "Standard-Template-Struktur" zu reorganisieren. So etwa sieht sie im Moment aus:
TS-Templates
- config
- lib
- page
- plugins
- tt
- temp
..., also, nach TLOs gegliedert. "tt" ist für tt_*. Bei "temp" sollen in das temp-Objekt Inhalte gespeichert werden, die dann Markern zugewiesen werden (.MARKER_1 < temp.meinemarker.MARKER_1).
Frage 1. Findet Ihr die Struktur grundsätzlich in Ordnung?
Frage 2. Objekt temp wird nicht gecachet. Sollte man nicht besser style oder lib nehmen? Wenn ja: nur wegen der Performance oder aus anderen Grünnden?
Frage 3. Kommt es oft bei Euch, dass Ihr das selbe Template mehrmals in dem selben Projekt verwendet?
Danke.
Hallo,
ich verwende nur lib.
zu deiner Struktur: ich würde mich nicht dort zurecht finden, weil in lib schmeiss ich zuviel rein.
zu deinem ersten bsp: config gehört unter config, auch wenns ein page.config ist, aber wie gesagt, du musst dich zurecht finden!
ad 3: meinst jetzt TS Template=? Wenn ja dann: natürlich! Hier in der Firma sind wir einige Leute und da ist eine gute, gleiche und optimierte Struktur das A & O
georg
Hallo!
just2b schriebad 3: meinst jetzt TS Template=?
Ich meine folgende Situation: Es gibt ein TYPO3-Projekt bzw. eine T3-Installation mit mehreren (Sub-)Domains bzw. (Sub-)Projekten:
root
- meine-homepage.de
-- foo
-- bar
- deine-seite.net
-- bla
-- yxcv
- subdomain.deine-seite.net
-- qwe
-- bar
-- bla
- noch-eine-seite.cn
- SysFolder TEMPLATES
Ist es oft der Fall, dass Du ein TS-Template z.B. in meine-homepage.de und subdomain.deine-seite.net verwendest, also dass mehrere Seiten des Seitenbaums das selbe Template referenzieren?
hab ich eigentlich nie, aber sonst ist das ja kein problem, einbinden msust du es ja sowieso, dann eben von nem anderen seite
georg
Ja, einbinden ist natürlich kein Problem. Der Hintergrund meiner Frage war das Problem der Namensgebung. Ich hab mich nämlich die letzten drei Tage mit der Frage beschäftigt, wie man die Dateien eines T3-Projekts benennen soll, nach welchem/-n Muster/-n. (Nicht, dass ich nichts besseres zu tun hab, aber das find ich halt wichtig.🙂) Dabei war eins der größten Dilemmas, ob die Dateiennamen über den Ort des Templates aussagen sollen (z.B. "root_self" für die Datei, deren TS nur auf der Root-Seite gelten soll, oder "meineseite_sub", wenn das TS nur für die Unterseiten der meineseite bestimmt ist, usw.). Daher die Frage.
du musst dich zurechtfinden, nicht wer anderer
georg
Ja, nein, jjjein... Das gleiche könnte man ja üder den Code sagen -- "Hauptsache, man kann seinen eigenen Code gut lesen". Trotzdem gibt es Code Conventions, die einem dabei helfen sollen, nicht nur eigenen, sondern auch noch den Code anderer zu verstehen. Aus dem gleichen Grund fänd ich übrigens eine (mehr oder weniger) standardisierte Dateien-Namensgebung für TYPO3-Projekte nicht schlecht (jedenfalls für kleine und mittelgroße Projekte). OK, das ist jetzt schon Offtopic... 🙂)