Templatename anzeigen

1st Official Post
    App
    WoltLab Suite Core

    Um die Anpassung von Templates zu erleichtern wäre eine Funktion hilfreich um überhaupt zu wissen welches Template was macht.

    In anderen Boards hat man die Möglichkeit durch eine Option sich Start und Ende von Templates im HTML Quelltext anzeigen zu lassen.

    Oft kann man bestimmte Dinge nicht aus dem Dateinamen des Templates ableiten und man fängt doch wieder an wild Kommentare in die Templates zu machen um überhaupt zu wissen welches genommen wird. Diese Funktion würde das komplett beheben.

    HTML
    <!-- start somename.tpl -->
<div>irgendwas</div>
<!-- end somename.tpl -->

    Reicht es nicht, dass das primär verwendete Template aus der ID für body eindeutig abgeleitet werden kann?


    Gruß norse

    Zugang zu meinen Arbeiten und dem dazugehörigen Support bekommt Ihr bei Interesse hier und hier.

    Du hast den Sinn dahinter nicht verstanden. ;)

    Es geht nicht um das primäre Template, sondern im Code aufzulisten welche Bereiche aus welchem Template genau stammen, um sich nicht groß durch die Template-Files zu wühlen, wenn man etwas z.B. in einer fest, aber über ein Template, eingebundenen Sidebarbox etwas ändern will. Ein gutes Beispiel ist auch die Beitrags- und Thread-Liste, die bis zu 4fach verschachtelt ist, wenn ich das nicht verwechsle.

    Ich hatte die Intention dahinter schon verstanden und auch an Dinge wie z. B. die Einbindung von userInformation gedacht (deshalb ja auch die Formulierung "primäres" Template.). Insofern war die Frage exakt so gemeint, wie ich sie formuliert hatte. Diese mehrfach verschachtelten Gefüge wie bei den genannten Beispielen sind ja nun nicht in jedem Template an der Tagesordnung, so dass ich es bisher nicht ausgesprochen mühselig fand, den gewünschten Abschnitt zu finden.


    Gruß norse

    Zugang zu meinen Arbeiten und dem dazugehörigen Support bekommt Ihr bei Interesse hier und hier.

    Ich sehe zumindest keinen Grund, der gegen diese Kennzeichnung der Templates sprechen würde. An den Debug Modus gekoppelt klingt das schon sinnvoll. Das würde es speziell Neulingen sicher erleichtern, sich in den Templates zurecht zu finden. Wer die Templates erstmal alle kennt, der braucht das natürlich nicht mehr. Aber schaden würde die Kennzeichnung ja niemandem.

    Quote from norse

    so dass ich es bisher nicht ausgesprochen mühselig fand

    Das mag sein wenn man die Templates kennt, wenn man sie nicht kennt ist es reines Rätselraten was durchaus schon mal bisschen dauern kann.

    Besonders bei dem ganzen verschachtelten Templates ist es sehr zeitaufwändig das entsprechende zu suchen wo man mit den Kommentaren sofort sieht wo es ist. Für Leute die sich perfekt auskennen sicherlich sinnlos, für die anderen 99% der Benutzer sicherlich eine Erleichterung.

    • Official Post

    Ich habe es mal testweise umgesetzt und ein paar Dinge ausprobiert. Am Ende habe ich mich dazu entschlossen die Änderungen wieder zu verwerfen, da dies mit einer ganzen Reihe an Nachteilen bzw. Problemen einhergeht:

    • Kommentare tauchen bspw. in JavaScript bei Element.childNodes mit auf, wodurch potentiell es zu fehlerhaften Verhalten kommt, wenn die Prüfung des nodeType nur unzureichend erfolgt. Ebenso erscheinen Kommentare innerhalb von Node.innerHTML, dies wird oft genug verwendet, inklusive einer Prüfung des Inhalts. Dies betrifft nur teilweise unseren eigenen Code (den man im Zweifel auch anpassen kann), aber nicht zu letzt auch Drittplugins im Hinblick auf die volle Abwärtskompatibilität.
    • Includes kommen sehr häufig zum Einsatz und werden so beispielsweise auch ganz am Anfang der Seite ausgegeben, etwa beim Einbinden von documentHeader.tpl, womit die Kommentare noch vor der DOCTYPE-Deklaration stehen. Dies ist eine mögliche Fehlerquelle und gerade Abweichungen im DOM werden von Browsern stillschweigend zurechtgebogen, leider können so mitunter kaum nachvollziehbare Fehler entstehen.
    • Konstrukte auf Basis von {hascontent} müssen angepasst werden, da der Inhalt bei includes auf Grund der Kommentare nicht länger leer ist. Logisch sind sie in solchen Fällen zwar immer noch leer, de facto ist dem aber nicht so. Ein Risiko besteht hier insbesondere bei Konstrukten die nicht auf {hascontent} aufbauen, da diese nicht von uns zentral angepasst werden können.
    • JavaScript wird üblicherweise an das Ende der Seite verschoben, dadurch entsteht der Eindruck leerer Templates bzw. zugehöriges JavaScript befindet sich nicht länger an der "erwarteten" Stelle. Das ist so ziemlich das geringste Problem von allem, sollte aber aus meiner Sicht nicht gänzlich unter den Tisch fallen.

    Eine Umsetzung im Rahmen der kommenden Version kommt aus den oben genannten Gründen vorerst nicht in Frage, ich schließe eine mögliche Realisierung in zukünftigen Versionen aber nicht vollkommen aus. Gegebenenfalls muss ein anderer Ansatz gewählt werden, um die oben genannten Probleme zu vermeiden.

    Alexander Ebert
    Senior Developer WoltLab® GmbH

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login