You shouldn't use inline JS for backend pages

Fragen zur Installation von CONTENIDO 4.9? Probleme bei der Konfiguration? Hinweise oder Fragen zur Entwicklung des Systemes oder zur Sicherheit?
Antworten
malsdgtac
Beiträge: 717
Registriert: Fr 12. Mär 2004, 15:50
Kontaktdaten:

You shouldn't use inline JS for backend pages

Beitrag von malsdgtac »

Hallo,

ich hätte da eine Verständisfrage. Ich bekomme folgende Meldung im deprecatedlog.txt angezeigt:

Code: Alles auswählen

Deprecated call: addScript() [class.page.php(220)]: "You shouldn't use inline JS for backend pages"
	addScript() called in file include.mod_overview.php(254)
	include_once() called in file main.php(185)
Okay, da steht, dass ich für Backendseiten kein Inline-Javascript verwenden soll. Aber kann mir jemand erklären warum, bzw. wie ich es statt dessen machen soll? Und was mache ich mit Javascript, welches z.B. dynamisch vom Modul generiert werden soll?
xmurrix
Beiträge: 3215
Registriert: Do 21. Okt 2004, 11:08
Wohnort: Augsburg
Hat sich bedankt: 4 Mal
Danksagung erhalten: 17 Mal
Kontaktdaten:

Re: You shouldn't use inline JS for backend pages

Beitrag von xmurrix »

Hallo smac,

das ist mehr ein Hinweis für Entwickler gedacht, die am CONTENIDO Core arbeiten. In der Regel werden Seiten, oder Teile von Seiten, im Backend mit der Klasse cGuiPage generiert, das ist wohl die Vorgehensweise für die Zukunft.
...Aber kann mir jemand erklären warum, bzw. wie ich es statt dessen machen soll?...
Auch möchte man im Backend soweit wie möglich von inline JavaScript Code wegkommen, wenn möglich, soll alles in JS Dateien ausgelagert werden. Es ist besser, wenn der JavaScript Code an einer Stelle bleibt, z. B. im js Ordner und wenn möglich nicht in Templates oder in PHP Scripten generiert wird. Das macht den Code wartbarer und sauberer. Außerdem hat man so eine saubere Frontendapplikation, in der das Markup (HTML), die Formatierung (CSS) und die Logik (JS) sauber voneinander getrennt ist.

Es kann aber auch sein, dass das nicht zu 100% möglich sein wird. Manchmal wird man nicht darauf verzichten können, im Markup, z. B. am Ende des body-Tags JS Code auszugeben. Auf jeden Fall werden addScript() Funktionsaufrufe der Klasse cGuiPage momentan als deprecated geloggt.
...Und was mache ich mit Javascript, welches z.B. dynamisch vom Modul generiert werden soll?...
Modulausgaben sind davon nicht betroffen, du kannst weiterhin JavaScript Code in Modulen ausgeben. Sofern du nicht cGuiPage->addScript() verwendest, ist es kein Problem. Willst du das aber auch soweit wie möglich strikt voneinander trennen, kannst du ja die Modul JavaScript-Datei mit der Logik implementieren und im Modulcode nur ein Funktionsaufruf mit der dynamisch generierten JavaScript Konfiguration machen, so wie man es von jQuery Plugins kennt...

Gruß
xmurrix
CONTENIDO Downloads: CONTENIDO 4.10.1
CONTENIDO Links: Dokumentationsportal, FAQ, API-Dokumentation
CONTENIDO @ Github: CONTENIDO 4.10 - Mit einem Entwicklungszweig (develop-branch), das viele Verbesserungen/Optimierungen erhalten hat und auf Stabilität und Kompatibilität mit PHP 8.0 bis 8.2 getrimmt wurde.
malsdgtac
Beiträge: 717
Registriert: Fr 12. Mär 2004, 15:50
Kontaktdaten:

Re: You shouldn't use inline JS for backend pages

Beitrag von malsdgtac »

Hallo,

vielen Dank für deine ausführliche Antwort. Verstehe ich es richtig, dass die Meldung aus dem Core und nicht aus meinen Modulen/Templates kommt und ich die Meldung daher gar nicht "wegbekomme"?

Dann brauche ich auch nicht länger danach zu suchen ;-)
xmurrix
Beiträge: 3215
Registriert: Do 21. Okt 2004, 11:08
Wohnort: Augsburg
Hat sich bedankt: 4 Mal
Danksagung erhalten: 17 Mal
Kontaktdaten:

Re: You shouldn't use inline JS for backend pages

Beitrag von xmurrix »

Ja, das kommt ganz sicher nicht aus Modulen/Templates, da diese nicht die cGuiPage Klasse verwenden. Es geht rein um inline JavaScript, das im Backend generiert wird.
CONTENIDO Downloads: CONTENIDO 4.10.1
CONTENIDO Links: Dokumentationsportal, FAQ, API-Dokumentation
CONTENIDO @ Github: CONTENIDO 4.10 - Mit einem Entwicklungszweig (develop-branch), das viele Verbesserungen/Optimierungen erhalten hat und auf Stabilität und Kompatibilität mit PHP 8.0 bis 8.2 getrimmt wurde.
Antworten