\n in einem <<<END Block

[Encoder]

Hallo
Ich stelle gerade meine Scripte um. Ich packe die ganze Ausgabe erst mal in eine Variable, da ich während dem Zusammenstellen evtl. noch ein Cookie im Header setzen will.
Jedenfalls gibts jetzt keinen HTML-Ausgabemodus mehr. Stattdessen stelle ich alles mit
$text = <<<END
...
$variable
...
END;
zusammen. Das Problem ist, ich habe sowas hier im Code: alert('Das hier ist\nein Test');
Leider wird das \n auch als Zeilenumbruch für den gesamten Code gesehen, da steht dann
alert('Das hier ist
ein Test'); und der ganze Code ist kaputt.

In der früheren Version hat das natürlich funktioniert. Kann ich da irgendwas einstellen, dass in so einem Textblock kein \n berücksichtigt wird?
Und wo find ich Infos zum Verhalten von <<<? Google ignoriert die Zeichen leider, egal ob sie in " " stehen oder nicht.

[Beat]

zusammen. Das Problem ist, ich habe sowas hier im Code: alert('Das hier ist\nein Test');
Leider wird das \n auch als Zeilenumbruch für den gesamten Code gesehen, da steht dann
alert('Das hier ist
ein Test'); und der ganze Code ist kaputt.

Du willst, dass '\n' als Literal ausgegeben wird, nicht als Umbruch interpretiert wird.
Dann schreibe \n.

mfg Beat

[Encoder]

Dann schreibe \n.

Ich Esel! Danke :-)

Ich hab mich so drauf versteift dass ich den bestehenden Code nicht ändern muss bzw. will. Aber das ist wenigstens eine Lösung, auch wenn sie mir - eben durch die nötigen Änderungen - nicht ganz so gut gefällt.

Wie sieht denn die sinnvollste Vorhegensweise bei sowas aus? Ich hab erst mal die Seite an sich statisch geschrieben, damit das Layout schon mal passt. Dann packe ich das alles in ein Script und fülle das dynamische dazu. Habt ihr Tips wie man das möglichst eins zu eins übernehmen kann?
Ok diese eine Änderung ist nicht wirklich schlimm, aber wenns da noch was schönes gibt ...

[hotti]

hi,

Ok diese eine Änderung ist nicht wirklich schlimm, aber wenns da noch was schönes gibt ...

Naja, bei mir waren es paar mehr Änderungen, die mir freundlicherweise ein Perlscript und

$in =~ s/\/&#92/g;

abgenommen hat.

Hotte

[Edgar Ehritt]

Hallo Encoder,

wenn Du schon Deine Scripte umstellst, warum gehst Du es dann halbherzig an? Gliedere doch gleich den gesamten HTML/CSS/JS-Kram in separate Dateien aus.

Wo früher vielleicht sowas zu finden war <p><?php echo $var; ?></p>, könntest Du dann in den Templates <p>&var;</p> notieren und mittels str_replace() (o. ä.) ersetzen lassen.

Anfänglich ist das eine Umstellung. Die Vorteile überwiegen dann doch im längerfristigen Arbeiten, wenn sich Programmlogik von getrennt wartbarem HTML-Templates (weiter-)entwickeln lässt. Auch die von Dir geschilderte Problematik und vergleichbare Hürden fallen ganz selbstverständlich weg.

Gruß aus Berlin!
eddi

[dedlfix]

echo $begrüßung;

wenn Du schon Deine Scripte umstellst, warum gehst Du es dann halbherzig an? Gliedere doch gleich den gesamten HTML/CSS/JS-Kram in separate Dateien aus.

Das muss nicht immer günstig sein. Es gibt Lösungsansätze die trennen nicht einzelne Code-Arten voneinander sondern die Verarbeitungsschritte. Ein Ansatz ist das EVA-Prinzip (Eingabewerte sammeln, verarbeiten, Ausgabe erstellen), ein anderer ist das MVC-Pattern.

Wo früher vielleicht sowas zu finden war <p><?php echo $var; ?></p>, könntest Du dann in den Templates <p>&var;</p> notieren und mittels str_replace() (o. ä.) ersetzen lassen.

Anfänglich ist das eine Umstellung. Die Vorteile überwiegen dann doch im längerfristigen Arbeiten, wenn sich Programmlogik von getrennt wartbarem HTML-Templates (weiter-)entwickeln lässt.

Dafür ergeben sich ganz andere Probleme. &placeholder; zu ersetzen ist für einzelne Werte nicht schlecht. Doch man will auch mal Datenbankinhalte als Massendaten in der Ausgabe stehen haben. Und nun?

• Eine Komponente schreiben, die für diesen Teil das HTML erzeugt, das statt an der &placeholder;-Stelle eingefügt wird? Damit ist man weniger flexibel, was den HTML-Code der Massendaten angeht, denn der versteckt sich im Code der Komponente.
• Die Template-Syntax um ein Wiederhol-Element erweitern? Das bringt einen bedeutend höheren Aufwand mit sich, als ein str_replace(). Man muss zunächst den Block im Ganzen finden und darin die Platzhalter berücksichtigen. Vielleicht ist auch noch im konkreten Anwendungsfall eine Verschachtelung von Blöcken notwendig ...

Außerdem verlässt man mit einem zusätzlichen Template-System die PHP-Philosophie oder anders gesagt, man setzt auf die Template-Engine PHP noch ein Template-System oben drauf. Dazu muss man eine Menge Stringverarbeitung machen, der auszugebende String wird bei dessen Erstellung mehrfach umkopiert, jedes Mal mit mehr Daten darin, und ganz am Ende wird ein großer Batzen an den Webserver und den Client geliefert. Wenn der für die Ausgabeerstellung zuständige Programmteil seine bereits erledigten Teile gleich rausschickt, werden weniger Ressourcen benötigt und der Browser kann auch schon mit dem Rendern anfangen. Bettet man PHP-üblich die variablen Anteile der Ausgabe in <?php-?>-Blöcke und lässt die statischen Teile außerhalb liegen, können diese gleich zum Webserver durchgereicht werden, ohne PHP-Ressourcen zu belegen.

Die Übersicht leidet nicht (eher im Gegenteil), wenn man also zuerst nach dem EVA-Prinzip das Berechnen oder Besorgen der Daten erledigt und dann im HTML-Teil nur noch der für die Ausgabelogik benötigte Code steht. Dies optisch ansprechend und übersichtlich zu gestalten bleibt dann noch eine Frage des Coding Style.

echo "$verabschiedung $name";

[Edgar Ehritt]

Hallo dedlfix,

| Wo früher vielleicht sowas zu finden war <p><?php echo $var; ?></p>, könntest Du dann in den Templates <p>&var;</p> notieren und mittels str_replace() (o. ä.) ersetzen lassen.

(ganz genau lesen und verstehen ;)

...und für "oder ähnliches" kann, für Deine Anführung - sollte, man eigene Funktionen schreiben.

In dem Sinne, dass einer Verschachtelung zu große Stringoperationen folgen und ein zeitnahes Rendern verzögert würde, ist diese Betrachtung IMHO nur halb bis zum Schluss gedacht. So sehe ich auch bei den jetzigen Bandbreiten der Nutzer den Flaschenhals immer noch bei der Datenmenge. Kompression ist hier das Stichwort. Datenkompression, um gute Ergebnisse zu erreichen, benötigt aber von vornherein eine Ausgabepufferung. Je größer der Puffer ist, desto besser arbeiten aber die Kompressionsalgorithmen. Was also anfänglich eine Hürde scheint, ist im Ganzen sogar ein Plus.

In einer Intranetlösung stimme ich Dir jedoch zu.

Gruß aus Berlin!
eddi