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)

Boah. Wahnsinn. Himi, sorry, aber manchmal frag ich mich echt ob dir zu helfen ist.

RegExen sind langsam. Das gilt fuer jede Art davon. Ich zeig dir mal einen Performance-Test:

zusammenfalten · markieren

PHP-Quellcode:

$preg = '#Foobar#i';
$toMatch = 'Foobar';

$sample = 'Foobar';

$num = 100000;

$pregStart = microtime(true);
$i = 0;
while ($i < $num) {
   preg_match($preg, $sample);
   $i++;
}
$pregStop = microtime(true);

$eqStart = microtime(true);
$i = 0;
while ($i < $num) {
   ($sample == $toMatch);
   $i++;
}
$eqStop = microtime(true);

echo 'Time preg: '. ($pregStop-$pregStart) .' seconds<br />';
echo 'Time eq: '. ($eqStop-$eqStart) .' seconds<br />';

Die Ausgabe bei mir:

Zitat:

Time preg: 0.75503706932068 seconds
Time eq: 0.045335054397583 seconds

Soll heissen: vermeide preg wenn es nicht sein muss. Wenn benoetigt wird dann gibts keinen Weg drumrum. Ich habe einen Fall wo ich eine URL der Form <md5>.png in latex.php?id=<md5> umwandeln muss. Das geht nicht ohne mod_rewrite. Wenn ich es jetzt aber verwende um eine saubere URL-Struktur reinzubringen, bin ich echt selber Schuld (also sowas wie /forum/Foo-Bar/topic/Blabla/50 zu viewtopic.php?t=50 umzuschreiben) und verdien nichts besseres als eine sacklangsame Applikation.

Aber, wenn du auf solchen Sachen rumreiten willst, bitte. Du hast nach einer Meinung gefragt und sie gekriegt. Du musst halt damit leben dass sie nicht unbedingt das ist, was du dir erhofft hast.

Greetz
alcaeus

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.

*seufz* Leute, es geht hier nicht um gut oder schlecht. Man sollte sich aber ueberlegen, ob man wirklich Regular Expressions einsetzen muss.

@himitsu: dein Vergleich hinkt genauso - mein Beispiel berief sich auf genau den Fall den ich (entweder in diesem Thema oder in einem anderen "Helft mir mit PHP"-Thema) beschrieben hatte.

Im konkreten Fall mussten fuer ein Ticketing-System das Support-Emails annimmt Blacklist-Eintraege geprueft werden. Die Blacklist kann auch Regex, weshalb auch vollstaendige E-Mail-Adressen als RegEx der Form "^foo@bar\.com$" gespeichert wurden. Dass das ein Performance-Loch (und das meine ich woertlich) sein kann, wurde damals gar nicht bedacht. Selbst wenn man dein Beispiel mit strpos nimmt, ein Faktor von zwei ist immer noch ein Faktor von zwei.

Was ich sagen will ist: pruef ob du etwas evtl. ohne preg machen kannst. Code wie z.B. return !preg_match('#^(\.|\.\.|\.htaccess|index\.htm(l)?)$#i', $FileName); ist naemlich absolut sinnbefreit und ausserdem schlecht testbar.

Greetz
alcaeus

PS da ich waehrend der preg-Untersuchung darauf gestossen bin:
$MailMask = '#^[\w.+-]{1,64}\@[\w.-]{1,255}\.[a-z]{2,6}$#'; Ich empfehle eine Lektuere von RFC 5322 und RFC 5321. Angenommen meine Mail-Adresse ist foo.bar|foobar@meinmailprovider.de. Willst du mir sagen dass ich keine Post von dir kriegen darf?
Kleiner Tipp an alle: wenn ihr schon ne Regular Expression schreibt, die E-Mail-Adressen validieren soll, dann macht euch bitte schlau wie eine Mail-Adresse aufgebaut ist. Auch der Hostname-Part der Validierung ist leider falsch.