Vernünftig inkludieren

[Jo]

Eine Frage zu sinnvoller Inkludierungstechnik.

/ (doc_root)

/inc

/us1
/us2
/us2/inc

skript.php in us2 inkludiert aus /us2/inc und aus /inc.

Eine Möglichkeit ist include ($_SERVER['DOCUMENT_ROOT'] . "/us2/inc/incskrpt.php") und include ($_SERVER['DOCUMENT_ROOT'] . "/inc/incskrpt.php").

incskrpt.php in /inc inkludiert wiederum incskrpt1.php und incskrpt2.php aus /inc:

include($_SERVER['DOCUMENT_ROOT'] . "inc/incskrpt1.php") und
include($_SERVER['DOCUMENT_ROOT'] . "inc/incskrpt2.php")

chdir ist keine gute Alternative. In Betracht käme noch __FILE__.

Jetzt kommt das Problem:

Auf dem Entwicklungsserver weicht die Struktur ab:

/
/ws1
/ws2/

/ws2/inc
/ws2/us1
/ws2/us2
/ws2/us2/inc

Es ist eine Ebene hinzugekommen. Die korrekten Includes müßten das ergänzen, z. B.:

include($_SERVER['DOCUMENT_ROOT'] . "/ws2/inc/incskrpt.php")

Das ergibt ein heilloses Durcheinander. Meine Überlegung, wie man das "synchronisieren" kann: Eine Konstante DEVELOPMENT zeigt an, ob auch Produktions- oder Entwicklungsserver gearbeitet wird:

define(DEVELOPMENT, true)

if (DEVELOPMENT == true)
  include($_SERVER['DOCUMENT_ROOT'] . "/ws2/inc/incskrpt.php");
if (DEVELOPMENT == false)
  include($_SERVER['DOCUMENT_ROOT'] . "/inc/incskrpt.php")

Ist meine Überlegung sinnvoll? Gibt es noch Alternativen, die ich bisher übersehen habe? In Betracht käme noch außerdem, wie schon angedeutet, mit absoluten Pfaden aus __FILE__ zu inkludieren.

[dedlfix]

echo $begrüßung;

Gibt es noch Alternativen, die ich bisher übersehen habe?

Verwende relative Verweise von einem innerhalb der Scripte nicht näher spezifizierten Verzeichnis ausgehend und konfiguriere den include_path auf den beteiligten Systemen so, dass dieses Verzeichnis darin genauer benannt aufgenommen wird. Dazu eignen sich die Per-Verzeichnis-Konfigurationen, falls mehrere Projekte unterschiedliche Einstellungen benötigen oder man nicht allein auf der Maschine ist, oder die Systemkonfiguration von PHP.

echo "$verabschiedung $name";

[wahsaga]

hi,

Gibt es noch Alternativen, die ich bisher übersehen habe?

Verwende relative Verweise von einem innerhalb der Scripte nicht näher spezifizierten Verzeichnis ausgehend und konfiguriere den include_path

Weitere Alternative: Verwende nicht $_SERVER['DOCUMENT_ROOT'], sondern eine eigene Konstante, die aus $_SERVER['DOCUMENT_ROOT'] "plus x" besteht, als Präfix für alle derartigen Operationen. Die ist schnell geändert, wenn das ganze bei gleichbleibender Struktur um eine oder mehrere Ebenen im Dateisystem "verschoben" wird.

gruß,
wahsaga

[Jo]

Weitere Alternative: Verwende nicht $_SERVER['DOCUMENT_ROOT'], sondern eine eigene Konstante, die aus $_SERVER['DOCUMENT_ROOT'] "plus x" besteht, als Präfix für alle derartigen Operationen. Die ist schnell geändert, wenn das ganze bei gleichbleibender Struktur um eine oder mehrere Ebenen im Dateisystem "verschoben" wird.

Das hört sich gut an. Kannst Du das näher erläutern? Meinst Du sowas:

include($base_dir . "/inc/incskrpt.php");

statt

include($_SERVER['DOCUMENT_ROOT'] . "/inc/incskrpt.php");

bzw.

include($_SERVER['DOCUMENT_ROOT'] . "/ws2/inc/incskrpt.php");

wo dann z. B. in einer Konfiguratonsdatei

$base_dir gesetzt wird, und zwar eine config für den Produktionsserver mit

$base_dir = $_SERVER['DOCUMENT_ROOT']

und eine andere für den Entwicklungsserver mit

$base_dir = $_SERVER['DOCUMENT_ROOT'] . "/ws2" ?

Kann sein, daß das einfacher zu handhaben ist, als eine fallweise Unterscheidung, wie inkludiert werden soll.

[wahsaga]

hi,

Das hört sich gut an. Kannst Du das näher erläutern? Meinst Du sowas:

Ja -

include($base_dir . "/inc/incskrpt.php");

• bis darauf, dass ich eine Konstante vorschlug. Der Wert wird sich ja schliesslich im Scriptverlauf nicht mehr ändern - und ihn versehentlich irgendwo zu überschreiben, was ja ziemlich blöd käme, kann auch nicht mehr passieren.

$base_dir = $_SERVER['DOCUMENT_ROOT'] . "/ws2" ?

define('BASEDIR', $_SERVER['DOCUMENT_ROOT'].'/ws2');
...
include(BASEDIR.'/inc/incskrpt.php');

(Für Konstanten Bezeichner in Großbuchstaben zu wählen, ist eine gängige Konvention.)

gruß,
wahsaga

[Jo]

Hi,

ich denke, ich mache das jetzt so:

In der Datei /ws1/us1/index.php (und in allen anderen Skripten) steht

include("./include/include_all.php");

Hier ist einmal eine relative Angabe nötig, da die Definitionen erst noch folgen. Das stört aber nicht weiter, solange sich die Relationen nicht ändern.

In include_all.php steht (verkürzt)

include("./include/config.php");

include(DOC_ROOT . "include/skript1.php");
include(DOC_ROOT . "include/skript2.php");

usw.

include(DOC_ROOT . "us1/include/skript1.php");
include(DOC_ROOT . "us1/include/skript2.php");

In der config.php in /ws1/us1/include werden die Pfade definiert

DEFINE("DEVELOPMENT_MODE", true);
DEFINE("DEBUG", true);

if (DEVELOPMENT_MODE == true)
    define('DOC_ROOT', $_SERVER('DOCUMENT_ROOT') . '/' . 'ws1' . '/');
else
    define('DOC_ROOT', $_SERVER('DOCUMENT_ROOT') . '/';

In ws1/include kann ich so noch eine andere config.php für andere Bereiche nutzen. Ich denke, so ist das relativ unabhängig von der tatsächlichen Verzeichnishierarchie.

Noch eine Nebenfrage: Sollte ich bei der Definition der Konstanten ein "/" manuell hinzufügen, oder eher nicht? Was sagt die Erfahrung?

[Jo]

Verwende relative Verweise von einem innerhalb der Scripte nicht näher spezifizierten Verzeichnis ausgehend und konfiguriere den include_path auf den beteiligten Systemen so, dass dieses Verzeichnis darin genauer benannt aufgenommen wird. Dazu eignen sich die Per-Verzeichnis-Konfigurationen, falls mehrere Projekte unterschiedliche Einstellungen benötigen oder man nicht allein auf der Maschine ist, oder die Systemkonfiguration von PHP.

Keine Ahnung, ob das nicht neue Probleme aufwirft, die bei der manuellen Verwaltung ausgehend von document root nicht aufträten. Kannst Du die Vorgehensweise an einem kleinen Beispiel erläutern?

[dedlfix]

echo $begrüßung;

Verwende relative Verweise von einem innerhalb der Scripte nicht näher spezifizierten Verzeichnis ausgehend und konfiguriere den include_path auf den beteiligten Systemen so, dass dieses Verzeichnis darin genauer benannt aufgenommen wird.
Kannst Du die Vorgehensweise an einem kleinen Beispiel erläutern?

Gegeben ist:

/ (docroot)
/inc
/us1
/us2
/us2/inc

Du inkludierst docroot-Dateien ohne Verzeichnis-Angabe und die anderen mit vorangestelltem inc/, us1/, us2/ und us2/inc/. include_path enthält einen Eintrag zum Documentroot. include sucht nun eine Datei inc/foo.php als /path/to/docroot/inc/foo.php.
Auf dem Entwicklungsrechner gibst du im include_path /path/to/docroot/ws2 an, und inc/foo.php wird daraufhin in /path/to/docroot/ws2/inc/foo.php gesucht.

echo "$verabschiedung $name";

[Jo]

Gegeben ist:

/ (docroot)
/inc
/us1
/us2
/us2/inc

Du inkludierst docroot-Dateien ohne Verzeichnis-Angabe und die anderen mit vorangestelltem inc/, us1/, us2/ und us2/inc/. include_path enthält einen Eintrag zum Documentroot. include sucht nun eine Datei inc/foo.php als /path/to/docroot/inc/foo.php.
Auf dem Entwicklungsrechner gibst du im include_path /path/to/docroot/ws2 an, und inc/foo.php wird daraufhin in /path/to/docroot/ws2/inc/foo.php gesucht.

So ähnlich, wie der Code, den ich zuletzt gepostet habe. Demnach könnte man auf dem Produktionssystem den Include-Path einfach auf den doc-root setzen und auf dem Entwicklungssystem z. B. auf doc-root/ws1/, wenn ich das jetzt richtig verstanden habe. Ich könnte mir jetzt vorstellen, daß es Probleme gibt, wenn auf dem Entwicklungsserver mehrere Projekte liegen. Ich denke, den Include-Path kann man nur global für den Server einstellen und nicht je Projekt unterschiedlich. Dann wäre die andere Variante, ein base-dir in einer Config-Datei zu definieren, etwas flexibler.

[dedlfix]

echo $begrüßung;

Ich könnte mir jetzt vorstellen, daß es Probleme gibt, wenn auf dem Entwicklungsserver mehrere Projekte liegen. Ich denke, den Include-Path kann man nur global für den Server einstellen und nicht je Projekt unterschiedlich.

Für jede php.ini-Direktive ist im Handbuch erwähnt, an welchen Stellen sie geändert werden kann. include_path ist PHP_INI_ALL-Changeable. Das heißt, du kannst es pro Verzeichnis und selbst im Script noch ändern.

echo "$verabschiedung $name";

[Jo]

Für jede php.ini-Direktive ist im Handbuch erwähnt, an welchen Stellen sie geändert werden kann. include_path ist PHP_INI_ALL-Changeable. Das heißt, du kannst es pro Verzeichnis und selbst im Script noch ändern.

"Eine Liste von Verzeichnissen, getrennt durch einen Doppelpunkt unter UNIX oder ein Semikolon unter Windows."

include_path=".:/php/includes"

Sind hier zwei Verzeichnisse angegeben? Worauf beziehen sich die Pfade? Werden die Verzeichnisse der Reihe nach abgearbeitet, oder wie muß ich mir das vorstellen? Wie legt man es im Skript selbst fest?

Kannst Du die Möglichkeiten mal anhand des Beispiels

/ = doc-root
/ws1/
/ws1/inc/

/ws2/
/ws2/inc/
/ws2/us1/inc/

durchspielen?

[wahsaga]

hi,

"Eine Liste von Verzeichnissen, getrennt durch einen Doppelpunkt unter UNIX oder ein Semikolon unter Windows."

include_path=".:/php/includes"

Sind hier zwei Verzeichnisse angegeben?

Nach dem, was du gerade zitiert hast, wird's wohl so sein :-)

Worauf beziehen sich die Pfade?

Auf das Verzeichnis . (das ist das aktuelle Verzeichnis), und auf das Verzeichnis /php/includes

Werden die Verzeichnisse der Reihe nach abgearbeitet

Ja.
Deshalb sollte man den include_path auch nicht zu voll packen - denn sonst sucht der Interpreter sich durch eine ganze Latte von Verzeichnissen, und findet die angegebene Datei womöglich erst im letzten oder gar nicht - nicht sonderlich performant.

Wie legt man es im Skript selbst fest?

Wie man Konfigurationseinstellungen ändert

So, vor den nächsten Fragen schaust du jetzt aber bitte erst mal selbst im Handbuch nach.

gruß,
wahsaga

[Jo]

include_path=".:/php/includes"

Sind hier zwei Verzeichnisse angegeben?

Nach dem, was du gerade zitiert hast, wird's wohl so sein :-)

Alles klar. Weil mir die Arbeitsweise, in welcher Reihenfolge oder überhaupt wie die Verzeichnisse inkludiert werden, nicht ganz klar war, konnte ich es so nur vermuten.

Worauf beziehen sich die Pfade?

Auf das Verzeichnis . (das ist das aktuelle Verzeichnis), und auf das Verzeichnis /php/includes

Letzteres ausgehend von doc-root?

Werden die Verzeichnisse der Reihe nach abgearbeitet

Ja.

Aber dann kann es zu Problemen führen, wenn zwei Skripte mit gleichem Namen in den Verzeichnissen existieren!

Deshalb sollte man den include_path auch nicht zu voll packen - denn sonst sucht der Interpreter sich durch eine ganze Latte von Verzeichnissen, und findet die angegebene Datei womöglich erst im letzten oder gar nicht - nicht sonderlich performant.

Das leuchtet mir ein. Schlägst Du die Lösung mit include_path vor oder aus Gründen der Performanz eher die andere mit Konstanten?

Wie legt man es im Skript selbst fest?

Wie man Konfigurationseinstellungen ändert

So, vor den nächsten Fragen schaust du jetzt aber bitte erst mal selbst im Handbuch nach.

Mache ich gern. Leider weiß ich manchmal nicht so genau, wonach oder an welcher Stelle ich suchen soll.

[wahsaga]

hi,

Werden die Verzeichnisse der Reihe nach abgearbeitet

Ja.

Aber dann kann es zu Problemen führen, wenn zwei Skripte mit gleichem Namen in den Verzeichnissen existieren!

Nö - dann wird einfach das erste gefundene genommen.

gruß,
wahsaga

[Jo]

Aber dann kann es zu Problemen führen, wenn zwei Skripte mit gleichem Namen in den Verzeichnissen existieren!

Nö - dann wird einfach das erste gefundene genommen.

Ne, so war das nicht gemeint. Ich meinte, zwei Skripte mit gleichem Namen aber unterschiedlichen Funktionen. Wenn im Kontext das Skript aus dem zweiten Verzeichnis benötigt würde, der Parser aber das Skript aus dem ersten nimmt, hat man ein Problem. Ich denke, das kann man über manuelle Inkludierung feiner handhaben.

[dedlfix]

echo $begrüßung;

Aber dann kann es zu Problemen führen, wenn zwei Skripte mit gleichem Namen in den Verzeichnissen existieren!
Nö - dann wird einfach das erste gefundene genommen.
Ne, so war das nicht gemeint. Ich meinte, zwei Skripte mit gleichem Namen aber unterschiedlichen Funktionen. Wenn im Kontext das Skript aus dem zweiten Verzeichnis benötigt würde, der Parser aber das Skript aus dem ersten nimmt, hat man ein Problem. Ich denke, das kann man über manuelle Inkludierung feiner handhaben.

Das kann man über eindeutige Bezeichnung der Dateien und geschickt gewählte Verzeichnisstruktur besser verwalten. Schau dir mal den Aufbau des Zend Frameworks an. Die Klassen sind eindeutig benamst und liegen außerdem im vom Klassennamen ableitbaren Verzeichnissen. Damit kann man sich sogar die Inkludiererei sparen und diese Aufgabe der Spezialfunktion __autoload() übertragen. Das setzt allerdings die konsequente Nutzung von OOP voraus.

echo "$verabschiedung $name";

[Jo]

Die Klassen sind eindeutig benamst und liegen außerdem im vom Klassennamen ableitbaren Verzeichnissen. Damit kann man sich sogar die Inkludiererei sparen und diese Aufgabe der Spezialfunktion __autoload() übertragen. Das setzt allerdings die konsequente Nutzung von OOP voraus.

Hi,

das hört sich nach einer interessanten Alternative an. Wäre es nicht geschickt, PHP hätte von Haus aus dieses Vorgehen zu schauen, ob eine Klasse im Skript definiert wird und, wenn nicht, zu versuchen, sie zu laden, implementiert?

[dedlfix]

echo $begrüßung;

... __autoload() ...
das hört sich nach einer interessanten Alternative an. Wäre es nicht geschickt, PHP hätte von Haus aus dieses Vorgehen zu schauen, ob eine Klasse im Skript definiert wird und, wenn nicht, zu versuchen, sie zu laden, implementiert?

Du meinst, dass der jetzige, seit Version 5.habsvergessen nutzbare Mechanismus bereits mit einer gewissen Grundfunktionalität vorbelegt sein soll? Was der eine geschickt nennt, kann der andere nicht verwenden, weil es nicht zu seinen Bedürfnissen passt. Und nach welchen Konventionen soll denn eine Suche stattfinden? Es ist doch jedem selbst überlassen, wie er seine Klassen auf Dateien verteilt. Die Implementierung ist schon gut, so wie sie jetzt ist. Der Mechanismus ist da, der Anwender muss ihn nur mit Leben füllen, so wie er es für richtig hält, und so wie es in seine Umgebung passt.

echo "$verabschiedung $name";

[Jo]

Du meinst, dass der jetzige, seit Version 5.habsvergessen nutzbare Mechanismus bereits mit einer gewissen Grundfunktionalität vorbelegt sein soll?

Ja.

Was der eine geschickt nennt, kann der andere nicht verwenden, weil es nicht zu seinen Bedürfnissen passt. Und nach welchen Konventionen soll denn eine Suche stattfinden? Es ist doch jedem selbst überlassen, wie er seine Klassen auf Dateien verteilt.

So, wie beim iclude_path auch. Entweder darüber, oder eine eigene Konfigurationsmöglichkeit include_classes_path. Eine weitere Option auto_include_class, automatisches Einbinden von Klassen an- und abzuschalten.

Die Implementierung ist schon gut, so wie sie jetzt ist. Der Mechanismus ist da, der Anwender muss ihn nur mit Leben füllen, so wie er es für richtig hält, und so wie es in seine Umgebung passt.

Es war nur eine Idee, ob das nicht Standardverhalten sein sollte.

[dedlfix]

echo $begrüßung;

Was der eine geschickt nennt, kann der andere nicht verwenden, weil es nicht zu seinen Bedürfnissen passt. Und nach welchen Konventionen soll denn eine Suche stattfinden? Es ist doch jedem selbst überlassen, wie er seine Klassen auf Dateien verteilt.
So, wie beim iclude_path auch. Entweder darüber, oder eine eigene Konfigurationsmöglichkeit include_classes_path. Eine weitere Option auto_include_class, automatisches Einbinden von Klassen an- und abzuschalten.

Das ist zu kompliziert. Es gibt keine eindeutige Zuordnung zwischen einer Klasse und der Datei, in der sie deklariert ist. Das Durchsuchen eines Verzeichnisses nach einem Dateinamen ist deutlich einfacher als das Öffnen aller Dateien in einem Verzeichnis und Analysieren deren Inhalts. Selbst dann noch, wenn beispielsweise mittels Jokerzeichen die Dateien auf *.php beschränkt werden. Solch ein Feature hat meiner Ansicht nach mehr Missbrauchs- und Frustpotential (z.B. wegen schlechter Performance) bei weniger erfahrenen Anwendern als es letzlich hilfreich ist. Wer mittlerweile so weit ist, OOP einsetzen zu können, sollte auch das jetzige Feature __autoload() verstehen.

echo "$verabschiedung $name";

[Jo]

Das ist zu kompliziert. Es gibt keine eindeutige Zuordnung zwischen einer Klasse und der Datei, in der sie deklariert ist. Das Durchsuchen eines Verzeichnisses nach einem Dateinamen ist deutlich einfacher als das Öffnen aller Dateien in einem Verzeichnis und Analysieren deren Inhalts.

Nein, ich dachte es eher so, Klassenname = Dateiname.php (oder eine andere/ zusätzliche Erweiterungen). Also pro Datei eine (Namensraum-)Klasse. So könnte es für Bibliotheken sinnvoll sein. Eventuell ein zusätzliches Statement

autoload class name;

damit nicht der Parser bei jeder Klasse gezwungen ist zu suchen. Dann müßte es einen Befehl in der Art

register_autoload_classes geben, mit dem alle (Namen der) Autoloadklassen in eine spezielle Konfigurationsdatei geschrieben wird. Diese Konfigurationsdatei müßte dauerhaft auf dem Server gespeichert werden, d. h., das Skript zur Registrierung müßte genau einmal aufgerufen werden (oder beliebig oft, wenn sich etwas ändert). Sobald in irgendeinem Skript der Zugriff auf eine Klasse erfolgt, die noch nicht deklariert wurde, müßte der Parser in dieser Datei nachschauen, ob dort die Klasse als Auto-Include vorgesehen ist. Das könnte auch noch erweitert werden

autoload class name from verzeichnis und/ oder
autoload class naem from verzeichnis/datei.

Dann hätte man zusätzlich die Möglichkeit, mehrere (getrennte) Klassen in einer Klassendatei unterzubringen.

Wenn ich so drüber nachdenke, kann man das auch mit den vorhandenen Befehlen imitieren. Ist vielleicht eine Alternative dazu, wie ich es bisher mache (eine Include-Datei, in der alle benötigten Include-Dateien eingebunden werden). Würde es von PHP aber direkt gemacht, wäre es wohl schneller und übersichtlicher (zumindest könnte auch noch der Include des Masterincludes entfallen).

[Jo]

Nein, ich dachte es eher so, Klassenname = Dateiname.php (oder eine andere/ zusätzliche Erweiterungen). Also pro Datei eine (Namensraum-)Klasse.[1] So könnte es für Bibliotheken sinnvoll sein.

[1]So ist es ja auch jetzt schon:

<?php
function __autoload($class_name) {
    require_once $class_name . '.php';
}

$obj  = new MyClass1();
$obj2 = new MyClass2();
?>

Die von mir beschriebene Vorgehensweise (Konfigurationsdatei) hätte den Vorteil, den Pfad zu den einzubindenen Klassen genauer handhaben zu können. Der Vorteil, die Funktion __autoload nicht mehr in jedem Skript deklarieren zu müssen, ist wohl zugegebenermaßen sekundär. Ob meine Idee viel performanter ist, kann ich nicht beurteilen. Es war nur eine Idee.

[Jo]

Für jede php.ini-Direktive ist im Handbuch erwähnt, an welchen Stellen sie geändert werden kann. include_path ist PHP_INI_ALL-Changeable. Das heißt, du kannst es pro Verzeichnis und selbst im Script noch ändern.

Wenn PHP_INI_ALL angegeben ist, wäre der korrekte Weg über

ini_set('include_path', '.:/ws1/include/:/ws1/us1/include');

innerhalb eines Skripts? Habe damit bisher noch nicht gearbeitet, deswegen muß ich fragen.

[dedlfix]

echo $begrüßung;

Wenn PHP_INI_ALL angegeben ist, wäre der korrekte Weg über
ini_set('include_path', '.:/ws1/include/:/ws1/us1/include');
innerhalb eines Skripts?

Das ist eine Möglichkeit. Wenn der include_path bereits vom System vorbelegt ist, und man auf Dateien daraus zugreifen will, empfiehlt es sich, den neuen Wert aus dem alten plus den anzufügenden Verzeichnissen zu wählen.
Damit man flexibel bleibt, und mit den Tennzeichen nicht durcheinander kommt, kann man zum einen die vordefinierten Konstante PATH_SEPARATOR nutzen, zum anderen den alten Wert am PATH_SEPARATOR explodieren lassen, die neuen Verzeichnisse einzeln zum Array hinzufügen und dieses dann mit PATH_SEPARATOR implodieren.

Habe damit bisher noch nicht gearbeitet, deswegen muß ich fragen.

Nein, dieser Zwang besteht nicht. Etwas mehr Experimentierfreude und eine Testumgebung, die man notfalls auch mal gefahrlos komplett wieder neu aufsetzen kann, sollten es auch tun. :-) Man lernt ja auch aus seinen Fehlern, die man bei den Versuchen macht.

echo "$verabschiedung $name";

[Jo]

Das ist eine Möglichkeit. Wenn der include_path bereits vom System vorbelegt ist, und man auf Dateien daraus zugreifen will, empfiehlt es sich, den neuen Wert aus dem alten plus den anzufügenden Verzeichnissen zu wählen.

Wieso keine komplett eigenen Pfade? Aus Performanzgründen?

Damit man flexibel bleibt, und mit den Tennzeichen nicht durcheinander kommt, kann man zum einen die vordefinierten Konstante PATH_SEPARATOR nutzen, zum anderen den alten Wert am PATH_SEPARATOR explodieren lassen, die neuen Verzeichnisse einzeln zum Array hinzufügen und dieses dann mit PATH_SEPARATOR implodieren.

Habe damit bisher noch nicht gearbeitet, deswegen muß ich fragen.

Nein, dieser Zwang besteht nicht. Etwas mehr Experimentierfreude und eine Testumgebung, die man notfalls auch mal gefahrlos komplett wieder neu aufsetzen kann, sollten es auch tun. :-) Man lernt ja auch aus seinen Fehlern, die man bei den Versuchen macht.

Experimentieren, ja. Sinnlos seine Zeit verschwinden, weil einige an sich simple Dinge nicht ausreichend im Manual dokumentiert sind, ist aber etwas anderes.

[dedlfix]

echo $begrüßung;

Das ist eine Möglichkeit. Wenn der include_path bereits vom System vorbelegt ist, und man auf Dateien daraus zugreifen will, empfiehlt es sich, den neuen Wert aus dem alten plus den anzufügenden Verzeichnissen zu wählen.

Wieso keine komplett eigenen Pfade?

Das habe ich nicht abgelehnt. Ich ergänzte nur das übliche Vorgehen, inklusive der Bedingungen, wann es sinnvoll ist, es so anzuwenden.

echo "$verabschiedung $name";

[Jo]

Wenn der include_path bereits vom System vorbelegt ist, und man auf Dateien daraus zugreifen will, empfiehlt es sich, den neuen Wert aus dem alten plus den anzufügenden Verzeichnissen zu wählen.

Wieso keine komplett eigenen Pfade?

Das habe ich nicht abgelehnt. Ich ergänzte nur das übliche Vorgehen, inklusive der Bedingungen, wann es sinnvoll ist, es so anzuwenden.

Ist mir immer noch nicht klar, was die Bedingungen sind. Zusätzlich zu den vom System vorbelegten Include-Verzeichnissen, aus denen man evtl. Dateien verwenden will, kann man doch, so wie ich es verstanden habe, weitere eigene Pfade hinzufügen.

[dedlfix]

echo $begrüßung;

Wenn der include_path bereits vom System vorbelegt ist, und man auf Dateien daraus zugreifen will, empfiehlt es sich, den neuen Wert aus dem alten plus den anzufügenden Verzeichnissen zu wählen.

Wieso keine komplett eigenen Pfade?
Das habe ich nicht abgelehnt. Ich ergänzte nur das übliche Vorgehen, inklusive der Bedingungen, wann es sinnvoll ist, es so anzuwenden.
Ist mir immer noch nicht klar, was die Bedingungen sind.

Die Bedingung leitete meinen oben zitierten Satz ein: "Wenn ... bereits ... vorbelegt ist, und man ...[darauf] zugreifen will"

Zusätzlich zu den vom System vorbelegten Include-Verzeichnissen, aus denen man evtl. Dateien verwenden will, kann man doch, so wie ich es verstanden habe, weitere eigene Pfade hinzufügen.

Genau so. Und wenn du eben auf die global konfigurierten _auch_ zugreifen willst, _dann_ erweitern und nicht komplett neu setzen.

echo "$verabschiedung $name";

[wahsaga]

hi,

Experimentieren, ja. Sinnlos seine Zeit verschwinden, weil einige an sich simple Dinge nicht ausreichend im Manual dokumentiert sind, ist aber etwas anderes.

Was hältst du denn für nicht ausreichend beschrieben?

Wenigstens Grundkenntnisse darüber, wie man sich im Dateisystem bewegt, sollte jemand, der in PHP Programmieren will, schon mitbringen.

gruß,
wahsaga

[Jo]

Was hältst du denn für nicht ausreichend beschrieben?

Wenigstens Grundkenntnisse darüber, wie man sich im Dateisystem bewegt, sollte jemand, der in PHP Programmieren will, schon mitbringen.

Vieles. Was spricht beispielsweise dagegen, beim Include-Befehl kurz alle möglichen Einbindungsarten in der Art von

include("./datei.ext")
include("/datei.ext")
include("http://www.../datei.ext")

usw. mit kurzer Beschreibung aufzuführen? Hat man keine (genauen) Kenntnisse, wie im Dateisystem navigiert wird, bleibt nur selber probieren. Wenn man aber nicht täglich damit zu tun hat, vergißt man es auch schnell wieder. Eine Referenz sollte genau den Zweck erfüllen, Dinge, die man schon einmal konnte, die aber in Vergessenheit geraten sind, schnell nachschlagen zu können. An der Stelle finde ich die Referenz oft ungenügend, weil man wegen Kleinigkeiten und Banalitäten groß rumsuchen muß. Wohl dem, der ein gescheites Buch sein Eigen nennt.