nicht angemeldet
Der Martin
Der Martin
Der Martin
dedlfix
dedlfix
Der Martin
dedlfix
Der Martin
Der Martin
dedlfix
Hallo,
welche der Formen
Gunnar Bittersmann
<script language="php"> (manchmal auch gelesen <script language=php>)
....
</script>
oder
<?php
......
?>
ist vorzuziehen?
Hallo,
nutze immer <?php /* ... */ ?>.
script-Elemente dürfen kein language-Attribut besitzen.
Gruß, Daniel
Hi,
script-Elemente dürfen kein language-Attribut besitzen.
in HTML 4.01 dürfen sie - aber das ist ja hier gar nicht relevant, denn die öffnenden und schließenden script-Tags müssen ja ebenso wie bei der üblichen Schreibweise <?php ... ?> vom PHP-Interpreter "konsumiert" werden, tauchen also in der Ausgabe nicht mehr auf.
Ciao,
Martin
... <?php ... ?> vom PHP-Interpreter "konsumiert" werden, tauchen also in der Ausgabe nicht mehr auf.
Korrekt !
Da der Interpreter sie annimmt und nicht als Ausgabe wiedergibt ist es vollkommen "egal".
Zukunftstechnisch gesehen glaube ich kaum das PHP Versionen in Zukunft kein <?php ?> mehr unterstützen werden ;)
[latex]Mae govannen![/latex]
nutze immer
<?php /* ... */ ?>.
Soweit: Ja
script-Elemente dürfen kein language-Attribut besitzen.
Wie kommst du darauf? Bedenke, das dieses Script-Element nur _vor_ dem Parsen vorhanden ist, insofern sind HTML-Standards nicht anwendbar.
Stur lächeln und winken, Männer!
Kai
Hallo,
Hallo,
nutze immer
<?php /* ... */ ?>.
http://framework.zend.com/manual/en/coding-standard.coding-style.html - "For files containing only PHP code, the closing tag must always be omitted (See General standards)."
Gruß
jobo
Hallo,
http://framework.zend.com/manual/en/coding-standard.coding-style.html - "For files containing only PHP code, the closing tag must always be omitted (See General standards)."
Das würde ja allem bisher geschriebenen widersprechen!
مرحبا
http://framework.zend.com/manual/en/coding-standard.coding-style.html - "For files containing only PHP code, the closing tag must always be omitted (See General standards)."
Das würde ja allem bisher geschriebenen widersprechen!
Inwiefern?
mfg
Hallo,
Das würde ja allem bisher geschriebenen widersprechen!
Inwiefern?
... weil in dem Thread angegebenen Beispielen immer ?> am Ende angegeben war, ohne Hinweis auf die Ausnahme.
مرحبا
Inwiefern?
... weil in dem Thread angegebenen Beispielen immer ?> am Ende angegeben war, ohne Hinweis auf die Ausnahme.
Wenn du eine Ressource hast, in der nur PHP-Code steht, dann brauchst du diese ressource nicht mit "?>" zu schliessen, wo ist da ein Widerspruch?
Es ist keine Ausnahme-Regelung, sondern eine möglichkeit.
mfg
Wenn du eine Ressource hast, in der nur PHP-Code steht, dann brauchst du diese ressource nicht mit "
?>" zu schliessen, wo ist da ein Widerspruch?
Es ist keine Ausnahme-Regelung, sondern eine möglichkeit.
Hallo,
Ok - ich glaube Euch ja,
aber bisher habe ich nun einmal gelesen, dass jedes öffnende tag auch wieder geschlossen werden sollte.
Und was wäre daran:
it´ prevents the accidental injection of trailing white space into the response
schlimm?
مرحبا
Ok - ich glaube Euch ja,
Das freut mich ;)
Es muss nicht einmal nur PHP-Code sein. Probiere es doch einfach aus:
<?php /* index.php */
error_reporting(E_ALL | E_STRICT);
?>
<p>test</p>
<?php
echo ' 1';
/* index.php ends */
mfg
<?php /* index.php */
error_reporting(E_ALL | E_STRICT);
?>
<p>test</p>
<?phpecho ' 1';
/* index.php ends */
>
Vermutlich verstand ich obiges nicht.
Ich erhalte als Ausgabe
test
1
مرحبا
Ich erhalte als Ausgabe
test
1
Richtig, auch ohne das schliessende "?>".
Und die vermeintlichen Probleme entstehen nicht, wenn du auf das abschliessende "?>" verzichtest, sondern umgekehrt.
mfg
Hallo,
Richtig, auch ohne das schliessende "
?>".
Und die vermeintlichen Probleme entstehen nicht, wenn du auf das abschliessende "?>" verzichtest, sondern umgekehrt.
Ach, so!
Ich dachte, in einem Falle müsste durch die Angabe 'error_reporting(E_ALL | E_STRICT);'
eine Meldung kommen.
Hallo,
Und was wäre daran:
it´ prevents the accidental injection of trailing white space into the response
schlimm?
solange man mit PHP nur HTML-Code ausgibt, ist das vielleicht nicht weiter tragisch. Sobald man aber andere Ressourcen erzeugt (z.B. binäre Daten wie Bilder, oder Textdokumente, bei denen Whitespace nicht ignoriert wird), dann spielt das schon eine Rolle.
Ciao,
Martin
[latex]Mae govannen![/latex]
it´ prevents the accidental injection of trailing white space into the response
schlimm?
solange man mit PHP nur HTML-Code ausgibt, ist das vielleicht nicht weiter tragisch.
Auch bei HTML-Erzeugung via PHP kann es schwerwiegende Auswirkungen haben, im schlimmsten Fall das berüchtigte "Headers already sent", wenn eine Datei vor dem ersten header()-Aufruf includiert wurde und diese Leerzeilen hinter dem Schließ-Tag enthält. Und auch Zeilenumbrüche vor dem DOCTYPE in Verbindung mit IE...
Stur lächeln und winken, Männer!
Kai
Hallo,
Wenn du eine Ressource hast, in der nur PHP-Code steht, dann brauchst du diese ressource nicht mit "
?>" zu schliessen, wo ist da ein Widerspruch?
Es ist keine Ausnahme-Regelung, sondern eine möglichkeit.
... und gilt dies auch für eine php-Datei, die ich mit include oder inquire einfüge - im Gesamtdokument wäre das ?> ja nicht mehr am Ende der Datei.
Hi,
Wenn du eine Ressource hast, in der nur PHP-Code steht, dann brauchst du diese ressource nicht mit "
?>" zu schliessen, wo ist da ein Widerspruch?
Es ist keine Ausnahme-Regelung, sondern eine möglichkeit.
... und gilt dies auch für eine php-Datei, die ich mit include oder inquire einfüge
Ja.
im Gesamtdokument wäre das ?> ja nicht mehr am Ende der Datei.
Das ist egal. In der Hinsicht wird jede include-Datei separat behandelt.
Ciao,
Martin
Hi,
http://framework.zend.com/manual/en/coding-standard.coding-style.html - "For files containing only PHP code, the closing tag must always be omitted (See General standards)."
Das würde ja allem bisher geschriebenen widersprechen!
nein, es ist allgemein gängige Praxis bzw. eine gute Empfehlung, das schließende "?>" wegzulassen, wenn es sowieso am Dateiende ist. Dann ist nämlich auch ausgeschlossen, dass am Ende "aus Versehen" noch ein paar Leerzeilen in der Ausgabe landen.
Dem PHP-Parser ist das egal; für ihn ist das Script mit dem Dateiende automatisch auch zu Ende.
Ciao,
Martin
http://framework.zend.com/manual/en/coding-standard.coding-style.html - "For files containing only PHP code, the closing tag must always be omitted (See General standards)."
Das kann auch nur PHP: Aus einer Fehlertoleranz und Inkonsistenz des Parsers eine Lösung für das Problem finden, dass PHP als HTML-Präprozessor gedacht war, man heute aber richtige Programme darin zu schreiben versucht…
Mathias
Tach!
http://framework.zend.com/manual/en/coding-standard.coding-style.html - "For files containing only PHP code, the closing tag must always be omitted (See General standards)."
Das kann auch nur PHP:
Du meinst sicher Zend, denn das ist deren Coding-Standard. Das PHP-Handbuch meint lediglich, dass bevorzugt werden soll, es wegzulassen.
Aus einer Fehlertoleranz und Inkonsistenz des Parsers eine Lösung für das Problem finden, dass PHP als HTML-Präprozessor gedacht war, man heute aber richtige Programme darin zu schreiben versucht…
Was ist denn besser daran, am Dateiende noch auf einen oder zwei weitere Abschlüsse zu bestehen? Es ist Schluss - ob da noch ein Semikolon und ein ?> kommt, ändert nichts mehr daran. Ich sehe es eher als übertriebene Gründlichkeit, so etwas zu fordern.
Es steht auch nicht PHPs Philosophie im Weg, nach der es am Ende selbständig offene Ressourcen schließt.
dedlfix.
Was ist denn besser daran, am Dateiende noch auf einen oder zwei weitere Abschlüsse zu bestehen? Es ist Schluss - ob da noch ein Semikolon und ein ?> kommt, ändert nichts mehr daran. Ich sehe es eher als übertriebene Gründlichkeit, so etwas zu fordern.
Ich fordere es nicht. Aber wie du in diesem Thread siehst, entspricht es zunächst der Erwartung der Webautoren, weil sie die Regel gelernt haben, dass auf einen öffnenden Tag ein schließender folgt. Wenn man PHP als Markup-Präprozessor betrachtet, was Anfänger erst einmal tun, ist es nur konsistent, ?> zu notieren.
Ich halte es für keine saubere Lösung, Problemen wie »Headers already sent« so zu begegnen. Diese basieren auf dem Widerspruch zwischen PHP als Präprozessor versus PHP als reiner Code in separaten Dateien. Langfristig wäre hier eine Trennung, z.B. durch unterschiedliche Dateinamen, hilfreich. Klar, kurzfristig kann man dem nur mit Coding Guidelines beikommen.
Mathias
Die Diskussion um die "Headers" hat mich nun ganz verwirrt.
Wenn ich folgendes habe:
PGM1.php:
<?php
require_once ($_SERVER['DOCUMENT_ROOT'].$_SERVER['MyAkt_Domain_Subdir_Sprache'].'/inhalt.inc.php');
?>
und
inhalt.inc.php:
<?php
.....
.....
?>
Ist dann in beiden Dateien das endene "?>" wegzulassen?
Tach!
Ist dann in beiden Dateien das endene "?>" wegzulassen?
Das kann man so nicht beantworten, weil du nicht sagst, was nachher kommt. Das Szenario ist vielmehr ein anderes: wenn zwischen ?> und dem Dateiende kein auszugebendes Zeug mehr steht, kann das ?> weggelassen werden, egal was vorher kam.
dedlfix.
Hallo,
Die Diskussion um die "Headers" hat mich nun ganz verwirrt.
das war nicht die Absicht, ist aber auch nur schwer zu vermeiden. *seufz*
<?php
require_once ($_SERVER['DOCUMENT_ROOT'].$_SERVER['MyAkt_Domain_Subdir_Sprache'].'/inhalt.inc.php');
?>
> ~~~php
<?php
> .....
> .....
> ?>
Ist dann in beiden Dateien das endene "?>" wegzulassen?
Ja. Ähm, nein. Kommt drauf an. ;-)
Damit keine Missverständnisse aufkommen: Es handelt sich beim Weglassen des schließenden "?>" nicht um ein "Muss", sondern um ein "Kann". Der PHP-Parser braucht das "?>" nicht, wenn an der Stelle die Scriptdatei sowieso zu Ende ist - ebenso wie du bei einem Buch auch keine Extra-Seite am Schluss brauchst, auf der nur in großen Lettern "ENDE" steht. Du merkst von selbst, dass das Buch da aufhört.
Aber: Alles, was nach dem "?>" noch folgt, wird noch an den Client gesendet, ohne dass das noch irgendwie interpretiert wird. Und es gibt Fälle, in denen das nicht erwünscht ist oder gar üble Nebenwirkungen hat. Anstatt nun peinlich genau drauf zu achten, dass nach dem Ende des PHP-Codes keine weiteren Leerzeilen folgen, lässt man das Endesymbol einfach weg und schließt diese Fehlerquelle damit prophylaktisch aus. Das ist eine Empfehlung, ein guter Rat, mehr nicht.
Ciao,
Martin
مرحبا
PGM1.php:
<?php
require_once ($_SERVER['DOCUMENT_ROOT'].$_SERVER['MyAkt_Domain_Subdir_Sprache'].'/inhalt.inc.php');
?>
<?php
.....
.....
?>
Füge in die Datei "PGM1.php" ein paar manuelle Zeilenumbrüche ein, nach dem schliessenden "`?>`{:.language-php}".
~~~php
<?php // pgm.php
/* Programme */
?>
# Zeilenumbrüche lassen, diese Zeile entfernen
und dann in der index.php
<?php // index.php
require_once 'pgm.php';
/* Programme */
?>
~~~~~~html
<!DOCTYPE html>
<!-- HTML ausgabe -->
In der Quell-Ausgabe der index.php siehst du, was es mit der Empfehlung auf sich hat.
mfg
Tach!
Was ist denn besser daran, am Dateiende noch auf einen oder zwei weitere Abschlüsse zu bestehen? Es ist Schluss - ob da noch ein Semikolon und ein ?> kommt, ändert nichts mehr daran. Ich sehe es eher als übertriebene Gründlichkeit, so etwas zu fordern.
Ich fordere es nicht. Aber wie du in diesem Thread siehst, entspricht es zunächst der Erwartung der Webautoren, weil sie die Regel gelernt haben, dass auf einen öffnenden Tag ein schließender folgt.
Dann haben sie was falsch gelernt. Viele Elemente erfordern kein schließendes Tag, bei manchen ist es sogar verboten.
Wenn man PHP als Markup-Präprozessor betrachtet, was Anfänger erst einmal tun, ist es nur konsistent, ?> zu notieren.
Sollen sie es doch tun, mit den eventuellen Nebenwirkungen und ohne dass sie gezwungen werden.
Ich halte es für keine saubere Lösung, Problemen wie »Headers already sent« so zu begegnen. Diese basieren auf dem Widerspruch zwischen PHP als Präprozessor versus PHP als reiner Code in separaten Dateien. Langfristig wäre hier eine Trennung, z.B. durch unterschiedliche Dateinamen, hilfreich. Klar, kurzfristig kann man dem nur mit Coding Guidelines beikommen.
Langfristig würde das nur noch mehr Chaos verursachen, wenn es nun zwei PHP-Datei-Typen gibt. Der Nutzen ist äußerst gering, eine Abwärtskompatibilität nicht gegeben - und das nur wegen eines angeblichen Schönheitsfehlers..
dedlfix.
@@dedlfix:
nuqneH
weil sie die Regel gelernt haben, dass auf einen öffnenden Tag ein schließender folgt.
Dann haben sie was falsch gelernt. Viele Elemente erfordern kein schließendes Tag, bei manchen ist es sogar verboten.
„Tag“ war nicht ganz der richtige Begriff; es ist eher eine Art Klammer: '<?' bzw. '<?php' ist die öffnende Klammer, '?>' die schließende.
Als ich noch an einer PHP-basierten Plattform gewerkelt habe, waren dort auch in Models und Controllern keine '?>'. Lediglich in Views tauchten sie auf.
Qapla'
Hallo,
Ich halte es für keine saubere Lösung, Problemen wie »Headers already sent« so zu begegnen. Diese basieren auf dem Widerspruch zwischen PHP als Präprozessor versus PHP als reiner Code in separaten Dateien. Langfristig wäre hier eine Trennung, z.B. durch unterschiedliche Dateinamen, hilfreich. Klar, kurzfristig kann man dem nur mit Coding Guidelines beikommen.
Naja, beim Zend framework heißen Dateien mit HTML-Output ".phtml"
Gruß
jobo
Hallo,
Tach!
http://framework.zend.com/manual/en/coding-standard.coding-style.html - "For files containing only PHP code, the closing tag must always be omitted (See General standards)."
Das kann auch nur PHP:Du meinst sicher Zend, denn das ist deren Coding-Standard. Das PHP-Handbuch meint lediglich, dass bevorzugt werden soll, es wegzulassen.
Aus einer Fehlertoleranz und Inkonsistenz des Parsers eine Lösung für das Problem finden, dass PHP als HTML-Präprozessor gedacht war, man heute aber richtige Programme darin zu schreiben versucht…
Was ist denn besser daran, am Dateiende noch auf einen oder zwei weitere Abschlüsse zu bestehen? Es ist Schluss - ob da noch ein Semikolon und ein ?> kommt, ändert nichts mehr daran. Ich sehe es eher als übertriebene Gründlichkeit, so etwas zu fordern.
Es steht auch nicht PHPs Philosophie im Weg, nach der es am Ende selbständig offene Ressourcen schließt.
Nein, du verhindetst einen nicht erwünschten Output von Whitespaces, der dir bei Session zum Beispiel im Weg steht. Es gilt ja auch nur für Files, in denen kein Output generiert werden soll.
Gruß
jobo
Hi,
welche der Formen
<script language="php"> (manchmal auch gelesen <script language=php>)
....
</script>
> oder
> ~~~php
<?php
> ......
> ?>
ist vorzuziehen?
die zweite ist die übliche; dass die erste überhaupt möglich ist, wusste ich noch gar nicht. Habe ich jedenfalls noch nirgends angetroffen.
Ciao,
Martin
Hallo,
Das PHP-Manual empfiehlt
<?php ...... ?>
Wenn Du aber die ungeparsten Dokumente im Browser anschauen willst,
z.B. wenn Du viel HTML-Code hast und nur einen kleinen Bereich hast,
der mit PHP eingefügt wird, dann ist die Schreibweise
<script language="php"> ... </script>
von Vorteil, denn die Browser werden hier einfach nichts anzeigen
(da sie die Script-Sprache PHP nicht kennen), während sie beim ersten
Beispiel den PHP-Quellcode anzeigen werden, was hässlich aussieht.
Freundliche Grüsse
Thomas
Hi,
Wenn Du aber die ungeparsten Dokumente im Browser anschauen willst, z.B. wenn Du viel HTML-Code hast und nur einen kleinen Bereich hast, der mit PHP eingefügt wird, dann ist die Schreibweise
<script language="php"> ... </script>
von Vorteil, denn die Browser werden hier einfach nichts anzeigen (da sie die Script-Sprache PHP nicht kennen), während sie beim ersten Beispiel den PHP-Quellcode anzeigen werden, was hässlich aussieht.
nein, kein Browser wird den PHP-Code anzeigen, denn aus der Sicht eines HTML- oder SGML-Parsers stellt dieser Text ein unbekanntes Tag dar:
<?php $foo=0; bar() ?>
Erst wenn im PHP-Code das Zeichen '>' vorkommt, sieht ein gewöhnlicher HTML-Tagsoup-Parser das Ende des vermeintlichen Tags und zeigt den Rest wieder an. Dann ist die Schreibweise mit script-Tag dann wirklich günstiger.
Ciao,
Martin
Hallo Martin,
Danke für die Ergänzung.
Erst wenn im PHP-Code das Zeichen '>' vorkommt, sieht ein gewöhnlicher HTML-Tagsoup-Parser das Ende des vermeintlichen Tags und zeigt den Rest wieder an. Dann ist die Schreibweise mit script-Tag dann wirklich günstiger.
Genau. Ich habe mal eine kleine Testseite gemacht.
Doctype: HTML 4.01 Transitional.
<?php
$ausgabe="<p>Das ist <b>voll fett</b>!</p>";
echo $ausgabe;
?>
Hier zeigt der MS IE 9 nichts an; Firefox 11.0 und Opera 11.62 zeigen an:
Das ist voll fett!
"; echo $ausgabe; ?>
Das heisst, ab dem ersten > (dem von <p>) ist für sie das "unbekannte Tag" geschlossen, und der Rest ist eben Tagsoup, den sie zu interpretieren versuchen.
Wenn man den gleichen PHP-Code mit den SCRIPT-Tags einpackt, also
<script language="php">
$ausgabe="<p>Das ist <b>voll fett</b>!</p>";
echo $ausgabe;
</script>
dann zeigen alle drei genannten Browser nichts an.
Ich habe mich schon vor sehr langer Zeit (ca. 2003) mit dem Thema Schreibweisen zum Einbetten von PHP in HTML beschäftigt und kam damals zum Schluss, dass die Schreibweise mit den SCRIPT-Tags die empfehlenswerteste sei.
Ein weiteres Argument für die SCRIPT-Schreibweise ist/war eben auch, dass einige WYSIWYG-Editoren (z.B. MS Frontpage 2000) bei der <?php ... ?> Schreibweise den PHP-Quellcode einfach löschten, während sie SCRIPT-Bereiche unangetastet liessen.
Freundliche Grüsse
Thomas
Moin!
Genau. Ich habe mal eine kleine Testseite gemacht.
Doctype: HTML 4.01 Transitional.
<?php
$ausgabe="<p>Das ist <b>voll fett</b>!</p>";
echo $ausgabe;
?>
>
> Hier zeigt der MS IE 9 nichts an; Firefox 11.0 und Opera 11.62 zeigen an:
> Das ist voll fett!
> "; echo $ausgabe; ?>
> Das heisst, ab dem ersten > (dem von <p>) ist für sie das "unbekannte Tag" geschlossen, und der Rest ist eben Tagsoup, den sie zu interpretieren versuchen.
>
> Wenn man den gleichen PHP-Code mit den SCRIPT-Tags einpackt, also
> ~~~php
<script language="php">
> $ausgabe="<p>Das ist <b>voll fett</b>!</p>";
> echo $ausgabe;
> </script>
dann zeigen alle drei genannten Browser nichts an.
In beiden Fällen ist dein PHP kaputt und der Quellcode wird ausgeliefert. Sowas sollte nicht zur Bewertung von "Best Practice" herangezogen werden.
Im Gegenteil: Wenn der Browser alles schön versteckt - wie merkt man dann, dass was kaputt ist?
Ich habe mich schon vor sehr langer Zeit (ca. 2003) mit dem Thema Schreibweisen zum Einbetten von PHP in HTML beschäftigt und kam damals zum Schluss, dass die Schreibweise mit den SCRIPT-Tags die empfehlenswerteste sei.
Ich finde das gerade nicht!
Anfänger haben schon genug Probleme damit, zu verstehen, dass PHP serverseitig ausgeführt wird, und Javascript clientseitig. Wenn man diesen Unterschied jetzt auch noch subtil in dem language-Attribut eines Script-Tags versteckt, wird die Unterscheidbarkeit noch geringer.
Ein weiteres Argument für die SCRIPT-Schreibweise ist/war eben auch, dass einige WYSIWYG-Editoren (z.B. MS Frontpage 2000) bei der
<?php ... ?>Schreibweise den PHP-Quellcode einfach löschten, während sie SCRIPT-Bereiche unangetastet liessen.
Wer kaputte IDEs benutzt, die als Texteditor nichts taugen, dem ist sowieso nicht zu helfen. :)
Gegen die Script-Schreibweise spricht vor allem eines: Die Länge! Und als zweites: Die Ungebräuchlichkeit! Und als Drittes: Die Empfehlung seitens PHP für die PHP-Tags!
- Sven Rautenberg
Hallo Sven,
<?php
$ausgabe="<p>Das ist <b>voll fett</b>!</p>";
echo $ausgabe;
?>
>
> In beiden Fällen ist dein PHP kaputt und der Quellcode wird ausgeliefert. Sowas sollte nicht zur Bewertung von "Best Practice" herangezogen werden.
Was ist an dem PHP kaputt?
Gruß
Walli
Tach!
In beiden Fällen ist dein PHP kaputt und der Quellcode wird ausgeliefert. Sowas sollte nicht zur Bewertung von "Best Practice" herangezogen werden.
Was ist an dem PHP kaputt?
Das ist nicht die Frage. Die individuelle Webserver-Konfiguration ist nicht richtig, wenn PHP nicht ausgeführt, sondern der Code in den Dateien einfach so an den Browser gesendet wird.
dedlfix.