eigentlich 'ne recht nette Sache

markieren

Code:

function loadClass($name) {
  // zum Schutz, damit man hier kein Sicherheitsloch reinbekommt
  $name = str_replace(array('/', '\\', ':'), '_', $name);

  if ((($file = __DIR__ . "/includes/$name.inc.php") && file_exists($file))
       || (($file = __DIR__ . "/includes/$name.php") && file_exists($file)))
    require_once $file;
}

spl_autoload_register('LoadClass'), true);

schon hätte man einen Miniatur-Autoloader für ein kleines Projekt

nun nur noch alle Klassen nach /includes/ , jeweils in eine Datei mit dem Namen {Klassenname}.php

und schon kann man sich alle include/require sparen.

Moin,

Zitat von himitsu:

$name = str_replace(array('/', '\\', ':'), '_', $name);

mitdenken bitte. Versuch mal folgenden Code auszufuehren (jede Klasse einzeln):
class Foo\Bar { } class Foo/Bar { } class Foo:Bar { } Ersteres ist unter PHP 5.3 eine Namespace-Definition, da ist die Ersetzung echt doof (wobei ich jetzt auch keine Zeit habe zu gucken, was da dem Autoloader uebergeben wird). Alles andere wird dir der Parser wieder rueckwaerts an Kopf werfen, entsprechend kannst du die Ersetzung auch rauswerfen. Schliesslich ist da ja nichts drin was User-generated ist. Falls doch, zurueck an den Planungstisch und das Anwendungskonzept neu erstellen.

Ich empfehle uebrigens das Zend-Naming-Scheme:
<NS>_Class_Where_Parts_Represent_Folders. Vom include_path ausgehend wuerde er die Klasse in <NS>\Class\Where\Parts\Represent\Folders.php suchen. <NS> ist dabei dein "Namespace" (nicht zu verwechseln mit echten Namespaces). Der wurde eingefuehrt um Kollisionen zu vermeiden, wie z.B. zwischen dem heutigen Zend_Date (frueher nur "Date") und der PHP-Standard-Klasse Date. Bei dir koennte es z.B. FNSE_Controller_Abstract heissen.

Greetz
alcaeus

PS: mit User-generated meine ich bspw. sowas:

markieren

PHP-Quellcode:

$foo = $_GET['foo'];
$bar = new $foo();

Hmmmm, an den Namespace hatte ich garnicht gedacht, also daß man den auch da mit angeben kann.

Aber ich hatte irgendwo gelesen, daß z.B. bei einem direkten Aufruf von spl_autoload_call oder eben deinem new $foo(); , vorallem in Verbindung mit Usereingaben, da auch "Verzeichnisse" mit übergeben werden könnten.

Was "Probleme" bereiten würde, wenn man aus dem Klassennamen einen Dateinamen zusammenbastelt.

Nja, und darum wollte ich verhindern, daß hier Verzeichnissangaben im Klassennamen enthalten sind.


[edit]
Grade ausprobiert ... gibt keine Probleme mit Namespace

markieren

Code:

function LoadClass($Class) {
  echo $Class . '<br>';
}
spl_autoload_register('LoadClass', true);

$X = new Foo/Bar();

und bei   $X = new Foo:Bar(); kommt es zu einem Parse-Error.

Ich fasse zusammen:
class Foo\Bar {} gibt

Zitat:

Parse error: syntax error, unexpected T_NS_SEPARATOR, expecting '{' in test.php on line 3

class Foo:Bar {} gibt

Zitat:

Parse error: syntax error, unexpected ':', expecting '{' in test.php on line 3

class Foo/Bar {} gibt

Zitat:

Parse error: syntax error, unexpected '/', expecting '{' in test.php on line 3

So, jetzt noch mit deinem Code: mit einem : gibt's nen Parse error, mit nem / wird "Foo" uebergeben, mit nem \ wird "Bar\Foo" uebergeben.
Das heisst, du solltest wirklich nichts ersetzen, denn den Namespace kannst du (wenn richtig gemacht) direkt mit nem ".php" am Ende versorgen und dann nen file_exists() machen.

Zitat von himitsu:

Aber ich hatte irgendwo gelesen, daß z.B. bei einem direkten Aufruf von spl_autoload_call oder eben deinem new $foo(); , vorallem in Verbindung mit Usereingaben, da auch "Verzeichnisse" mit übergeben werden könnten.

Also, mein Code ausm PS ist ein Beispiel das du so nie machen solltest. Das ist ein Sicherheitsleck hoch 10. Auch einen direkten Aufruf von spl_autoload_call solltest du nie brauchen, und falls doch dann solltest du da keinen User-Generated content reinstopfen. Es gibt wirklich keinen Grund, UGC in eine solche Funktion zu schieben. Ganz ehrlich: Sicherheit sollte an der ersten Stelle stehn, das ist wohl klar. Das was du aber machst ist an der falschen Ecke gespart. Ueberleg dir wie du deine Anwendung baust und was PHP als gueltig betrachtest und du wirst nicht bei jedem Autoload-Call einen dummen, langsamen String-Replace machen muessen.

Greetz
alcaeus

Was mir grad so auffällt ...

Wenn RegExen doch sooooo böse sind und möglichst vermieden werden sollen,
dann darf man auch keine RewriteEngine verwenden, denn dieses Ding ist ja bis zum Rand damit vollgestopft.

Die sind auch nicht böse, nur verhältnismäßig langsam.
Das kommt immer auf den Anwendungsfall an.

Nja, weil sich doch "beschwert" wurde, daß ich ein paar davon verwendete.
(wobei sie nichtmal oft aufgerufen wurden)

Hi,

Zitat von himitsu:

Wenn RegExen doch sooooo böse sind und möglichst vermieden werden sollen,
dann darf man auch keine RewriteEngine verwenden, denn dieses Ding ist ja bis zum Rand damit vollgestopft.

im Prinzip hast du da auch Recht. Apache kann diese Regexen aber ganz toll (im kompillierten Zustand) zwischenspeichern. Bin mir im Moment auch gar nicht sicher, ob PHP das nicht auch irgendwie kann (sowas wie preg_compile?). Ich mag mod_rewrite auch nicht so besonders. Meine Applikationen bau ich auf, indem ich einfach alle URLs auf die index.php weiterleite - sofern die aufgerufene URL nicht als Datei wirklich existiert. (sinnvoll für statische Daten wie Bilder oder CSS)

Liebe Grüße,
Valle

Also ich hatte mit himitsu's Code so Mittel ca. (PHP 5.2 und PHP 5.3):

markieren

Code:

Time preg: 0.11731195449829 seconds
Time pos: 0.036504030227661 seconds

Dennoch würde ich sagen, dass es in vielen Fällen eine Fallentscheidung ist, ob reguläre Ausdrücke eingesetzt werden sollten oder nicht.
Bei seltenen Tasks kann man sie auf jeden Fall einsetzen. Bei Scripten, die ggf. häufig aufgerufen werden könnten, würde ich auf ausgiebigere Last-Tests ansetzen. Damit kann man ermitteln, ob eventuelle Bottlenecks wirklich am RegEx liegen oder nicht vielleicht doch an anderen Code-Stellen (DB-Zugriff, SQL-Statements, Design im allgemeinen...). Je nach Komplexität der Überprüfung, ist ein RegEx vielleicht sogar besser - wenn z.B. ein String sonst erst komplett zerbröselt werden müsste...

Edit: Bei meinem PHP Inspection Unit (siehe Signatur) Projekt wird ein PHP-Quelltext auch über reguläre Ausdrücke analysiert und im Endeffekt ist die Performance auch noch recht praktikabel (750 KB Quelltext in < 1 Sekunde) - ohne reguläre Ausdrücke wäre der Code viel länger und komplizierter (und somit schwieriger zu warten) geworden.