[Typo3-german] Eigenes Icon f?r jeden Eintrag im HMENU -- GELÖST

[JoH]

> na ein bisschen Lob hätte mir schon gutgetan ^-^

OK - die Lösung als solche ist ja auch technisch korrekt und funktionabel.
Lob und Anerkennung dafür ;-)

> Aber natürlich verstehe ich die Kritik -- richtiger wäre es anscheind
> eine "Advanced" Seite zu machen und als erstes ein NO Bildchen ins
> media hochzuladen, dann ein RO Bildchen und diese mit listNum
> anzusprechen.

Korrekt - damit bestünde nämlich auch noch die Möglichkeit, diese per
levelmedia anzusprechen und damit gleich ganze Teilbereiche des Seitenbaums
mit einem einzigen Satz von zwei Bildchen zu "beliefern".
Wobei listNum nicht zwingend notwendig ist, aber dazu später.

> Leider sind wie gesagt fast alle der Hauptkategorien-Seiten vom Typ
> "Shortcut" und der Seitentyp bietet keine Mediauploads an. Der
> Workaround wäre, die Bilder erst im Advanced hochzuladen und danach
> den Typ auf Shortcut zurückändern. Dies kann aber nicht
> garantieren, dass die Bilder auch erhalten bleiben, da Shortcut sie
> wie gesagt eigentlich nicht unterstützt.

Folgendes Setup definiert im TCA, welche Felder für "Shortcut" sichtbar sein
sollen:
$TCA['pages']['types']['4']['showitem'] = 'hidden;;;;1-1-1, doktype,
title;;3;;2-2-2, nav_hide, shortcut;;;;3-3-3, shortcut_mode,
TSconfig;;6;nowrap;5-5-5, storage_pid;;7, l18n_cfg';

Mit Hilfe einer kleinen Extension läßt sich dieser Eintrag abändern, damit
das "media" Feld sichtbar wird. Einfach "media" an der gewünschten Stelle
einfügen. Fertig!
$TCA['pages']['types']['4']['showitem'] = 'hidden;;;;1-1-1, doktype,
title;;3;;2-2-2, nav_hide, shortcut;;;;3-3-3, media, shortcut_mode,
TSconfig;;6;nowrap;5-5-5, storage_pid;;7, l18n_cfg';

> Ausserdem muss man die
> Bilder schön in der richtigen Reihenfolge hinterlegen.

Nicht notwendigerweise, denn auch bie Verwendung des media Felds bestünde
die Möglichkeit, genau wie bei Deinem Ansatz mit einer bestimmten
Namensgebung zu arbeiten und z.B. jeweils ein NO.gif und ein RO.gif
hochzuladen.
Diese werden automatisch mit einem suffix versehen, um sie unterscheiden zu
können.
Im TS-Setup für die Ausgabe könntest Du per if Abfrage und entsprechender
split Funktion steuern, welche der Dateien für den jeweiligen Zustand in
Frage kommt.
Allerdings halte ich es persönlich für einfacher, den Redakteuren
mitzuteilen, daß es eine bestimmte Reihenfolge gibt, obwohl ich zugeben muß,
daß die Fehlerhäufigkeit dadurch ggf. zunimmt.

> Weiterer
> Nachteil ist, dass sich die Seitenicons mit weiteren Seitenuploads,
> usw., mischen, d.h. das kann man auch nicht wirklich "CMS-like"
> nennen, eher im Gegenteil.

Wenn das wirklich ein Problem darstellt, wäre es doch durchaus intelligent
eine kleine Extension zu schreiben, die aus dem media field ein flexform
erzeugt, das über verschiedene Eingabefelder verfügt.
Dann hätten die Redakteure die Möglichkeit, exakt zu definieren, für welchen
Anwendungsbereich die jeweilige Datei gedacht ist.

> Desweiteren findet man die Seitenicons
> später nicht im Verzeichnis wieder (okay, braucht man nicht
> notwendigerweise, kann man ja vom CMS aus löschen) und eine Änderung
> an
> denen ist umständlicher als wenn man einfach die entsprechende Datei
> im speziellen "Seitenicons"-Verzeichnis mit der neueren Version
> überschreibt.

Das kann ich nun gar nicht nachvollziehen, weil der Aufwand mehr oder
weniger identisch ist. Ganz abgesehen davon, daß der Platz mit Hilfe des
eben erwähnten flexforms unabhängig vom Dateinamen eindeutig definiert
werden könnte.

> Auch zielen die Seitenicons eher auf das Seitendesign
> als auf den dahinterliegenden Content ab, von daher sind sie
> thematisch näher am Layout als am Inhalt, demzufolge sollten sie auch
> näher am Layout hinterlegt werden, sprich: als zusätzliche Dateien
> zum Template, wie ja auch die CSSs dort liegen. Würde man sie ins
> media legen mischten sie sich aber wiederum mit dem Inhalt.

Das ist dann eher Ansichtssache und von Fall zu Fall verschieden. Wir gehen
zum Beispiel in letzter Zeit vermehrt dazu über, mit einem Default CSS als
Template zu arbeiten, das mit Hilfe eines eigenen Seitentyps die jeweils
passenden CSS Parameter in eigens hierfür definierte Subparts und Marker
geschrieben bekommt. Das CSS "liegt" also eigentlich nirgendwo und wird für
die einzelnen Seiten dynamisch erzeugt, aber dennoch extern eingebunden. Ist
noch nicht zu 100% ausgereift, aber durchaus realisierbar.
Thematisch betrachtet läge es IMHO sogar näher, die CSS Datei (wenn sie
nicht sowieso dynamisch erzeugt wird) ebenfalls im media Feld der Root-Seite
zu deponieren.
Eine Abfrage per "levelmedia:-1, slide" lieferte dann entweder das "root
CSS" oder eine speziell für diesen Seitenbaum-Bereich vorgesehene Datei.

> Wie sähe denn deiner Meinung nach die "korrekte" und saubere Lösung
> aus?

Die optimale Lösung wäre IMHO:
1. Media Feld für "shortcut" aktivieren
2. Media Feld als Flexform rendern und per XML mit einem Set verschiededener
Upload Felder versehen
3. Das GMENU mit Hilfe von levelmedia:-1, slide (+ Flexformauswertung) die
einzelnen Grafiken in ein LOAD_REGISTER rendern lassen
4. Das Menu als <ul> Liste per TMENU erzeugen und mit separaten IDs pro Item
versehen
3. Die jeweils "zuständigen" Grafiken aus dem Register in einem dynamisch
erzeugten CSS file den jeweiligen IDs zuweisen

Komfortabel, sicher und barrierefrei. Aber zugegeben, in Deinem Fall eher
ein wenig oversized. ;-)

> Man lernt ja nie aus :) und mich interessiert es wirklich, kann ja
> sein, dass ich einfach Tomaten auf den Augen hatte und es eine ganz
> triviale Lösung für meine Aufgabe gegeben hätte.

Trivial wäre, nur das media Feld zu aktivieren und den Redakteuren zu sagen:
Die erste Datei muß immer die NO-Datei sein, die zweite immer die RO-Datei
und dann kommt ggf. der Rest.
Dazwischen gibt es sicherlich noch ein paar "Mittelwege" wie so oft bei
TYPO3 ;-)

Joey

-- 
Wenn man keine Ahnung hat: Einfach mal Fresse halten!
(If you have no clues: simply shut your knob sometimes!)
Dieter Nuhr, German comedian
openBC: http://www.openbc.com/go/invuid/Jo_Hasenau