Includes sauber beenden

[Stefan]

Hi, die meissten PHP Script basieren darauf andere Dateien
in einer Haupseite zu includen.

Das bedeutet aber zwangsläufig, dass die Funktionen die()
oder exit() nicht unbedingt in so einer inc. datei genutzt
werden sollten.

1. Fehlt der untere Bereich der Hauptseite, was zu
offenen Tags führt.

2. Bei manchen Scripten kommt nur noch eine leere Seite.

Bisher habe ich mir damit geholfen, indem ich eine Dummy-variable
hatte mit den wichtigsten nachfogenden Tags also:
$endingtags ='</div></body></html>';

Diese vor exit() oder im die(...) eingesetzt, springt sozusagen
als Double für den eigentlichen Rest ein.

Jetzt ist diese Lösung aber nicht gerade pflegeleicht und muss
immer individuell angepasst werden.

So dachte ich mir, vielleicht gibt es ja auch eine vordefinierte
Lösung in PHP die ich noch nicht kenne. Also praktisch sowas wie

exit_inc() so das der weitere Inhalt der inc. Datei ignoriert
wird und die Ausgabe wieder von der HAuptseite weitergeführt wird.

Gibt es sowas, oder wie macht ihr das?

Stefan

[Christoph Schnauß]

hallo,

Hi, die meissten PHP Script basieren darauf andere Dateien
in einer Haupseite zu includen.

Das halte ich für einen absoluten Irrtum.

Das bedeutet aber zwangsläufig, dass die Funktionen die()
oder exit() nicht unbedingt in so einer inc. datei genutzt
werden sollten.

Und auch das halte ich für einen absoluten Irrtum - falls es tatsächlich von jemandem so gebraucht wird, wird es sich in vielen Fällen um fehlerhaften bzw. schlampig geschriebenen Code handeln.

1. Fehlt der untere Bereich der Hauptseite, was zu
   offenen Tags führt.

Wieso?

2. Bei manchen Scripten kommt nur noch eine leere Seite.

Wieso?

Bisher habe ich mir damit geholfen, indem ich eine Dummy-variable
hatte mit den wichtigsten nachfogenden Tags also:
$endingtags ='</div></body></html>';

Da wäre wichtig, daß du angibst, warum du das so gemacht hat - und wieso du glaubst, damit irgendein "exit()" oder "die()" abgefangen bzw. ersetzt zu haben.

Diese vor exit() oder im die(...) eingesetzt, springt sozusagen
als Double für den eigentlichen Rest ein.

Kannst du das auch verständlich ausdrücken?

Jetzt ist diese Lösung aber nicht gerade pflegeleicht

Es ist allenfalls eine "Verlegenheitslösung", die man schleunigst wieder verlassen sollte, sobald der gesamte beabsichtigte Code komplettiert ist.

So dachte ich mir, vielleicht gibt es ja auch eine vordefinierte
Lösung in PHP die ich noch nicht kenne. Also praktisch sowas wie
exit_inc()

Nein, das gibt es nicht. Allerdings gibt es eine "vordefinierte" Lösung: lerne PHP-Sxripts korrekt zu schreiben.

Grüße aus Berlin

Christoph S.

[Sven Rautenberg]

Moin!

Hi, die meissten PHP Script basieren darauf andere Dateien
in einer Haupseite zu includen.

Das bedeutet aber zwangsläufig, dass die Funktionen die()
oder exit() nicht unbedingt in so einer inc. datei genutzt
werden sollten.

Vernünftiger Programmfluss ist immer ratsam.

Das führt dazu, dass man recht schnell zur klassischen Aufteilung der beteiligten Komponenten in Programmlogik und Ausgabelogik kommt. Und die Ausgabelogik wird dann üblicherweise durch eine Template-Engine realisiert.

Bleibt für die Programmlogik also schon mal weniger zu tun (diese Kapselung führt oft dramatisch zu mehr Übersichtlichkeit). Und das, was dann noch in Includefiles eingebunden wird, ist nur in den seltensten Fällen wirklich direkt ausführbarer Code - viel häufiger sind es Funktions- oder Klassendefinitionen, die der Programmlogik einfach nur zur Verfügung gestellt werden.

Dadurch treten Probleme wie diese hier:

1. Fehlt der untere Bereich der Hauptseite, was zu
   offenen Tags führt.

2. Bei manchen Scripten kommt nur noch eine leere Seite.

dann einfach gar nicht auf.

- Sven Rautenberg

[Christoph Schnauß]

hallo Sven,

Vernünftiger Programmfluss ist immer ratsam.

Das ist ein geradezu klassischer Orakelspruch, der der delphischen Pythia nur deswegen nicht zugeschrieben werden kann, weil es zu ihrer Zeit noch kein PHP gab.

Dadurch treten Probleme wie diese hier:
[...]
dann einfach gar nicht auf.

siehe oben.

Interessant und vielleicht diskutierenswert finde ich aber die Voraussetzungen, von denen Stefan offenbar sehr arglos ausgeht. Vermutlich sehen das einige andere ähnlich - daß man eben mit irgendwelchen "includes" herumwurschtelt und aus denen irgendeine "Hauptseite" zusammensetzt. Nicht, daß man das nicht so machen _könnte_ - aber _wo_ ist das sinnvoll, _wann_ braucht man es so, und _warum_ muß es unbedingt PHP sein, wenn doch oftmals auch (X)HTML alleine völlig ausreichen könnte? Vielleicht sollten wir _das_ auf fürs Archiv einigermaßen zitierenswerte Weise diskutieren.

Grüße aus Berlin

Christoph S.

[Stefan]

Hi Christoph,

Das ist ein geradezu klassischer Orakelspruch, der der delphischen Pythia nur deswegen nicht zugeschrieben werden kann, weil es zu ihrer Zeit noch kein PHP gab.

»»

Ihre Visionen beruhten auch auf Rauschzuständen.
Wie sagt dein Weinpegel im Moment eigentlich?

Dein anderes Posting hierzu lässt erkennen, dass du gar nicht
verstehst, um was es geht. Du fragst ja auch oft:
wieso?, weshalb?

Aber dennoch meinst du rumzumeckern, wobei du vielleicht sogar
gar zufällig oder aufgrund Svens Aussage gar nicht so falsch liegst.

Aber glaube mir mein Freund, selbst die Besten includen.
Und viele nutzen keine Template Engines sondern haben eigene
Routinen.

Interessant und vielleicht diskutierenswert finde ich aber die Voraussetzungen, von denen Stefan offenbar sehr arglos ausgeht. Vermutlich sehen das einige andere ähnlich - daß man eben mit irgendwelchen "includes" herumwurschtelt und aus denen irgendeine "Hauptseite" zusammensetzt. Nicht, daß man das nicht so machen _könnte_ - aber _wo_ ist das sinnvoll, _wann_ braucht man es so, und _warum_ muß es unbedingt PHP sein, wenn doch oftmals auch (X)HTML alleine völlig ausreichen könnte? Vielleicht sollten wir _das_ auf fürs Archiv einigermaßen zitierenswerte Weise diskutieren.

Fürs Archiv, oder für dich?
Hast du schon mal ein umfangreiches PHP Projekt geschrieben?

Du solltest nicht so herablassend hier über mich schreiben,
wenn du nicht mal die Ansätze verstehst.

Alleine deine Idee PHP Includes durch XHTML zu ersetzen,
lässt mich stark an dir zweifeln.

Normalerweise würde ich das hier nicht in dieser Form schreiben,
aber überleg mal ein wenig selbstkritisch wie herablassend
und arrogant ohne Anzeichen von Grundwissen du hier postest.

Stefan

[Christoph Schnauß]

hallo Stefan,

Wie sagt dein Weinpegel im Moment eigentlich?

Selbst wenn er Altgriechisch spräche, käme nur "null Allohol" heraus.

Dein anderes Posting hierzu lässt erkennen, dass du gar nicht
verstehst, um was es geht.

Du wirst mir zugestehen, daß ich das nicht so sehe.

Du fragst ja auch oft:
wieso?, weshalb?

Ja, gelegentlich - um das Nachdenken zu fördern. Wenn man sich einmal angewöhnt, selber nach Fehlermeldungen zu suchen, wäre es denkbar, daß etliche Anfragen hier im Forum nicht gestellt werden müßten.

Aber dennoch meinst du rumzumeckern

Ich wüßte nicht, daß ich "gemeckert" hätte - jedenfalls diesmal nicht.

wobei du vielleicht sogar
gar zufällig oder aufgrund Svens Aussage gar nicht so falsch liegst.

Ach ... Schön, daß du mir das zugestehst.

Aber glaube mir mein Freund, selbst die Besten includen.

Ich glaubs dir. Und ich bin dann eben keiner der "Besten". Ich komme in aller Regel ohne "include()" aus, auf den PHP-Projekten, die ich bisher erstellt habe, gab es allenfalls in der index.php ein
  require_once('Smarty.class.php');
und sonst weiter nix. Oder eben sonst weiter nur sehr wenig ...

Hast du schon mal ein umfangreiches PHP Projekt geschrieben?

Aber ja.

Du solltest nicht so herablassend hier über mich schreiben

Ich habe nicht "über dich" geschrieben, sondern versucht, den Ansatz, den du zu verfolgen scheinst, für eine weiterführende Diskussion aufzubereiten.

Alleine deine Idee PHP Includes durch XHTML zu ersetzen,
lässt mich stark an dir zweifeln.

Es gibt gewisse Unterschiede zwischen "mir" und Gestaltungsmöglichkeiten für Webseiten.

Grüße aus Berlin

Christoph S.

[King^Lully]

Nicht, daß man das nicht so machen _könnte_ - aber _wo_ ist das sinnvoll, _wann_ braucht man es so, und _warum_ muß es unbedingt PHP sein, wenn doch oftmals auch (X)HTML alleine völlig ausreichen könnte? Vielleicht sollten wir _das_ auf fürs Archiv einigermaßen zitierenswerte Weise diskutieren.
Alleine deine Idee PHP Includes durch XHTML zu ersetzen,
lässt mich stark an dir zweifeln.

An und für sich eine gute Idee, wir "ersetzen" nicht mehr bedarfsweise HTML durch PHP, sondern PHP durch HTML.
Ja, das wollte ich noch loswerden. Fürs Archiv und so.   ;)

[Tom]

Hello,

Aber glaube mir mein Freund, selbst die Besten includen.
Und viele nutzen keine Template Engines sondern haben eigene
Routinen.

Auch eigene Routinen können eine Template-Engine darstellen.
Die einfachste Art sind dann Templates, in die direkt die Ausgabebehälter eingestanzt werden in der Sprache, in der das Script läuft. Also hier durch <?php echo $_ausgabe['mitglieder']; ?>

Die andere Variante sind Voll-Templates, die das Design sprachunabhängig[1] bereitstellen, indem sie Platzhalter <!-- mitglieder --> bereithalten in der Sprache des Templates, aber unabhängig von der verwendeten Sriptsprache. Das hat den Vorteil, dass man dasselebe Template mit unterschiedlichen Scriptsprachen verwenden kann.

[1] unabhängig von der für die Verarbeitung genutzten Scriptsprache

Harzliche Grüße vom Berg
http://www.annerschbarrich.de

Tom

[eddi]

Hallo Stefan,

die Funktionen exit() gehört generell nicht in den Kontext einer Webanwendung. Sie ist auch nicht dazu bestimmt Textausgaben zu fertigen, sondern ist Die Funktion, die dem Programmierer ermöglicht, den exit status eines ausgeführten Programms zu setzten. (Dieser Status hätte zwar prinzipiell Bedeutung für den Server, der PHP via CGI anspricht, um dem Client mitzuteilen, wenn ein Programm auf einen Fehler traf und abbrach. Reell aber sieht das HTT-Protokoll soetwas nicht vor.)

Deine Lösung sollte hier return sein. Dazu konsultiere bitte die Dokumentation unter http://de3.php.net/manual/de/function.include.php#id2674289 beginnend ab "Der Umgang mit Returns:"!

Gruß aus Berlin!
eddi

[Blaubart]

Tach.

die Funktionen exit() gehört generell nicht in den Kontext einer Webanwendung. Sie ist auch nicht dazu bestimmt Textausgaben zu fertigen, sondern ist Die Funktion, die dem Programmierer ermöglicht, den exit status eines ausgeführten Programms zu setzten.

Mir fällt eigentlich nur eine Stelle ein, an der ein exit() im PHP-Code sinnvoll wäre: dort, wo ein selbstgeschriebener Error Handler einen Fehler feststellt, der die weitere Ausführung des Skripts nicht zuläßt. Statt dessen wird der Fehler geloggt, dem Client eine Fehlerseite ausgeliefert und das gesamte Skript mit exit() beendet.

[eddi]

Tach.

Ebenso.

die Funktionen exit() gehört generell nicht in den Kontext einer Webanwendung. Sie ist auch nicht dazu bestimmt Textausgaben zu fertigen, sondern ist Die Funktion, die dem Programmierer ermöglicht, den exit status eines ausgeführten Programms zu setzten.

Mir fällt eigentlich nur eine Stelle ein, an der ein exit() im PHP-Code sinnvoll wäre: dort, wo ein selbstgeschriebener Error Handler einen Fehler feststellt, der die weitere Ausführung des Skripts nicht zuläßt. Statt dessen wird der Fehler geloggt, dem Client eine Fehlerseite ausgeliefert und das gesamte Skript mit exit() beendet.

Es ist sicher nur ein Stilfrage, daß man eine Funktion zu dessen Zweck gebraucht. In Deinem Beispiel wird ebenso ein exit status erzeugt, den niemand sehen wird, noch interressiert. Daher wäre auch hier die() _meine_ Wahl.
 exit() ist hingegen in CLI-Scripten überaus hilfreich, wo anhand des Status Diagnose bertieben werden kann.

Gruß aus Berlin!
eddi

[Blaubart]

Tach.

Es ist sicher nur ein Stilfrage, daß man eine Funktion zu dessen Zweck gebraucht. In Deinem Beispiel wird ebenso ein exit status erzeugt, den niemand sehen wird, noch interressiert.

Aha. Vielleicht hätte ich "exit/die" schreiben sollen, denn es war nicht der Exit Code oder der Unterschied exit-die, auf den es mir ankam, sondern der Einsatz in einem Skript überhaupt. Abgesehen davon, daß ein ignorierter Exit Code in meinen Augen nun auch nicht das große Argument ist, würde ich dich bitte, folgendes auszuprobieren (mein Beispiel mit PHP 5.1.4):

  
$ php -a && echo "blupp"  
Interactive mode enabled  
  
<?php die; ?>  
blupp  
  
$ php -a && echo "blupp"  
Interactive mode enabled  
  
<?php exit; ?>  
blupp  

Dann meinetwegen auch nochmal mit die(0), die(1) und das gleiche für exit. Ich kann keine Unterschiede zwischen exit und die feststellen. die erzeugt also anscheinend ebenso "ein exit status, den" -- von CLI-Skripten abgsehen -- "niemand sehen wird, noch interressiert" wie es laut dir exit tut. Oder wie meintest du das?

Gruß aus Berlin!

Ebenso. :)

[eddi]

Re:

Ach - ich wußte es...

Es ist sicher nur ein Stilfrage, daß man eine Funktion zu dessen Zweck gebraucht. In Deinem Beispiel wird ebenso ein exit status erzeugt, den niemand sehen wird, noch interressiert.

... Abgesehen davon, daß ein ignorierter Exit Code in meinen Augen nun auch nicht das große Argument ist

Genau das meinte ich auch, als ich _Stilfrage_ schrieb. Relevant oder gar argumentationsfähig ist es tatsächlich nicht.

... Dann meinetwegen auch nochmal mit die(0), die(1) und das gleiche für exit. Ich kann keine Unterschiede zwischen exit und die feststellen. die erzeugt also anscheinend ebenso "ein exit status, den" -- von CLI-Skripten abgsehen -- "niemand sehen wird, noch interressiert" wie es laut dir exit tut. Oder wie meintest du das?

  
$ php -r 'die(7);'  
$ echo $?  
7 # Ausgabe  
  
$ php -r 'exit(7);'  
$ echo $?  
7 # Ausgabe  

Ups! Tja - hätte ich mal lieber vorher nochmals testen sollen ;)
Muß schon etwas länger her sein, daß ich dort einmal einen Unterschied (meinte?) wahrzunehmen. Tjo - Danke!

Gruß aus Berlin!
eddi

[Blaubart]

Tach.

Genau das meinte ich auch, als ich _Stilfrage_ schrieb. Relevant oder gar argumentationsfähig ist es tatsächlich nicht.

Ah, ok. Ich glaubte in dem "Es ist sicher nur ein Stilfrage ..." einen ironischen Unterton erkannt zu haben.

[Olaf Schneider]

Hallo,

ich würde hier recht konservativ in den drei Schritten Eingabe-Verarbeitung-Ausgabe denken. Die Eingabe nimmt die Anforderung (request) entgegen und entscheidet daran, was zu tun ist und mit welchen Werten. Die Verarbeitung erzeugt eine Antwort (Response), stellt diese aber nicht dar. Die Ausgabe zeigt diese Antwort schließlich an.

So hat man u. a. eine Trennung zwischen Logik und Ausgabe und das Aufbauen eines korrekten xhtml (oder eines Textes oder einer csv-Datei oder ..) ist wesentlich einfacher. Ob Du für das Aufbauen der Antwortdaten und deren Anzeige einfach ein Array mit Werten füllst, Smarty benutzt, einen xml-Baum erzeugst und transformierst oder ein eigenes Templatesystem benutzt, bleibt Dir überlassen.

Noch ein Hinweis. In den Includedateien sollten sich nur Funktionen, Klassen und Konstanten befinden und niemals direkt ausführbarer Code. Wenn man dann noch ein vernünftiges Naming wählt (Die Klasse MyTemplate hat den Pfad /lib/MyTemplate.php) geht auch die Übersicht nicht verloren.

Ich weiss, dass das nicht die genaue Antwort auf Deine Frage ist, aber sie zeigt eine Möglichkeit auf, mit der Deine Frage keine Relevanz mehr hat.

Gruß
Olaf

[Tom]

Hello,

man kann die() eine ganze valide HTML-Seite übergeben.

Das setzt natürlich voraus, dass man vorher noch nichts ausgegeben hat.

Wenn man seinen Code sauber strukturiert und wenigstens die drei Hauptbereiche

• Steuerung
• Verarbeitung
• Ausgabe

einhält, dann hat man ohnehin ein Halb- oder Volltemplate für die Ausgaben jeder Seite.

Die veränderlichen Daten werden mittels <?php echo $_ausgabebereich['xyz']; ?> (Halbtemplate) an den passenden Stellen eingefügt, oder PHP ersetzt (beim Volltemplate) eingefügte Platzhalter <!-- Platzhalter 233 --> durch einen extra Parserlauf. Dieser kann dann auch in einer Schleife solange laufen, wie Platzhalter gefunden werden. Das bedeutet, dass ein Wert, der einen Platzhalter ersetzt, auch wieder einen neuen Platzhalter enthalten kann. Das macht sehr elegant den Zusammenbau komplexer Inhalte aus Bausteinen möglich, kostet aber Rechenzeit...

Am Ende des Halb-Templates steht im Prinzip immer

</body>
   </html>
   <?php exit(); ?>

(vereinfacht dargestellt)

Harzliche Grüße vom Berg
http://www.annerschbarrich.de

Tom

[Tom]

Hello,

kleiner Nachtrag http://de.wikipedia.org/wiki/MVC

Ich hatte es vorhin nicht gleich wiedergefunden.

Harzliche Grüße vom Berg
http://www.annerschbarrich.de

Tom

[wahsaga]

hi,

man kann die() eine ganze valide HTML-Seite übergeben.

Wenn man seinen Code sauber strukturiert und wenigstens die drei Hauptbereiche

• Steuerung
• Verarbeitung
• Ausgabe

einhält, dann hat man ohnehin ein Halb- oder Volltemplate für die Ausgaben jeder Seite.

Wozu dann überhaupt noch sterben gehen?
Dann gebe ich doch lieber eine Fehlermeldung zurück, die ich dann in meinem Template als Ausgabe einfügen kann.

Wenn ich in der Verarbeitung doch wieder mit die() aussteige, und dabei ein komplettes HTML-Dokument _ausgebe_ - wo ist dann noch die saubere EVA?

gruß,
wahsaga

[Tom]

Hello,

man kann die() eine ganze valide HTML-Seite übergeben.

Wenn man seinen Code sauber strukturiert und wenigstens die drei Hauptbereiche

• Steuerung
• Verarbeitung
• Ausgabe

einhält, dann hat man ohnehin ein Halb- oder Volltemplate für die Ausgaben jeder Seite.

Wozu dann überhaupt noch sterben gehen?
Dann gebe ich doch lieber eine Fehlermeldung zurück, die ich dann in meinem Template als Ausgabe einfügen kann.

Wenn ich in der Verarbeitung doch wieder mit die() aussteige, und dabei ein komplettes HTML-Dokument _ausgebe_ - wo ist dann noch die saubere EVA?

Beenden muss man das Script, "sterben lassen" eben nicht. Da stimme ich Dir zu.
Wenn man es aber partout nicht lassen kann, mit die() zu arbeiten, kann man eine vollständige HTML-Seite als String übergeben. Nachteil: es fehlt dann die Fehlermeldung, wenn man einfach nur den String übergibt, ohne vorher z.B. mittels str_replace etwas zu ersetzen...

Da sind wir dann wieder beim Template.

ein Beispiel hatte ich unter http://selfhtml.bitworks.de/strukturierung/deleteliste.php

Die Funktion html() kann man dann an jeder Stelle im Script aufrufen, nach den Vereinbarungen, versteht sich. Ob man die Behälter da als Array übergibt und in der Funktion immer fragt if(isset() echo) oder ob man die Werte global setzt (was im Beispiel noch nicht ordentlich gemacht wurde) ist sicher Geschmackssache. Da es nur einen Response gibt, würde ich keine Skrupel haben, hierfür ein Unterarray in $GLOBALS zu benutzen. Oder habe ich da 'was übersehen? Könnte es passieren, dass man mehrere Instanzen der Ausgabe-Behälter benötigt?

Harzliche Grüße vom Berg
http://www.annerschbarrich.de

Tom