Paul!!: php function und javascript / Lösung

Beitrag lesen

Hi,

Warum machst Du das nicht schon serverseitig? Dann müsstest Du dich nicht darauf verlassen, dass der Client Javascript bereitstellt!

Das mache ich im Normalfall serverseitig. Ich könnte es auch hier serverseitig machen, dann müßte ich aber entweder den Zählvorgang doppelt durchführen lassen, ihn zwischenspeichern oder meine (spätere) include-Datei in 2 Dateien splitten. Alle 3 Optionen wären selbstredend locker möglich, würden aber insgesamt mehr Arbeit machen als einfach ein DIV zu generieren, in das der Client per JS einen Eintrag vornimmt. Da eh JQuery mitläuft, macht $('#mydiv').html('Mein Eintrag') das ganz vorzüglich. Und dazu ists auch angedacht.

Darauf verlassen, das der Client JS bereitstellt, muß ich mich ohnehin. Es geht hier um das Einbinden von OSM Daten über eine JS-Bibliotek. Das ist sozusagen nichts anderes als pures Javascript.

Das DIV widerum generiere ich dynamisch, und zwar über eine Funktion.

Daran ist ja auch ert einmal nichts auszusetzen. Das machen alle CMS irgedwie genauso.

Nicht wahr?...

Dass Du Probleme an Stellen verlagerst, an denen sie noch weiter wachsen? Wenn der Client kein Javascript unterstützt, funktioniert dein Apparat nicht mehr. Und irgendwie musst Du den einzusetzenden Wert ja ohnehin zum Client transportieren. Warum dann nicht gleich an der passenden Stelle?

  1. Wenn der Client kein JS will oder kann, ist die Funktion dieses Teils meiner Software ohnehin nicht nutzbar. (s.o.)

  2. Im Verlauf des Zeichnens dieser Karte entstehen die Daten. Sie sollten aber oberhalb der Karte als Überschrift stehen. Daher die Optionen:

  3. Einen Teil doppelt ausführen/ggf. zwischenspeichern.

  4. Die Inculde-Datei splitten.

  5. Per JS die Daten clientseitig über die Karte setzen.

Ich habe mich für Punkt 3 entschieden, weil es mit großem Abstand die wenigste Arbeit macht und das Gesamtkosntrukt der Programmteile unversehrt erhalten bleibt. Bedenke, ich nutze die anderen Programmteile noch in vielen anderen "Modulen"

Das ist also alles andere als ein Designfehler, insbesondere wenn die Gruppe der Clients bekannt ist und JS in allen (und in diesem Programmteil ganz besonders) zwingende Voraussetzung zur Programmnutzung ist.

Hier im Forum wird oft vorschnell etwas als Designfehler ausgemacht, was bei näherem Hinsehen nicht so ist.

Davon abgesehen: Es kann gute Gründe dafür geben, einen vermeintlichen Designfehler zu nutzen, wenn hierdurch ein anderer Nutzen entsteht. Beispiel Datenbank: Es kann vorteilhaft sein, eine begrenzte Anzahl von Daten redundant zu führen (Designfehler, nicht wahr?), wenn sich hierdurch an anderer Stelle ein für das Gesamtprojekt höherer Gesamtnutzen ergibt. Das kann bessere (menschliche) Lesbarkeit im Datenbackend für Supportfälle sein, das kann auch die ein oder andere Query sein, die hierdurch deutlich einfacher und/oder effizienter ist.

Paul