Zitat von himitsu:

zusammengesetzt und z.B. über mysql_real_escape_string abgesichert/maskiert.

So hab ich das bislang auch gemacht. Allerdings haben mich die PS überzeugt. Ich denke, ich werde meinen Code entsprechend umstellen.

Guck dir mal die PDO-Referenz an. Da siehst du was mit Prepared Statements gemeint ist

BTW (auch @Mithrandir): ich kann hier nur die Verwendung eines ORM (wie z.B. Doctrine) empfehlen.

Greetz
alcaeus

Zitat von alcaeus:

ich kann hier nur die Verwendung eines ORM (wie z.B. Doctrine) empfehlen.

Nu' hab ich ja schon 'ne fertige Datenbankklasse implementiert und komme eigentlich auch gut damit klar. Was wäre denn der Vorteil, ganz grob umrissen, den ich mit Doctrine hätte? Denn immerhin bedeutet das ja auch, dass ich mich in ein neues System einarbeiten müsste. Daher tue ich mich auch noch schwer, auf symfony umzuschwenken, zumal das System nahezu komplett ist.
Auf der anderen Seite könnte ich mir aber auch vorstellen, dass symfony einiges vereinfachen könnte. Hab mir mal das Tutorial mit der Job-Website durchgelesen. Grob erinnert mich so ein PHP-Framework an die VCL in Delphi.

Der Vorteil von Doctrine? Nu ja, nehmen wir an du hast eine Tabelle "Student" mit folgenden Spalten: id, lastname, firstname, birthday, matr.
Du hast entsprechend eine Klasse "Student" mit den Properties id, lastname, firstname, birthday, matr. Jedesmal wenn du Daten aus der Datenbank holst, werden automatisch die Objekte erzeugt, so dass du direkt damit arbeiten kannst:

markieren

PHP-Quellcode:

$student = Doctrine::getTable('Student')->findOneById($studentId);
if (!$student) {
// ...
}
$student->notifyAboutExams();

Das ist jetzt ein etwas stupides Beispiel, aber der Vorteil ist ganz eindeutig: jeder Datenbankzeile wird automatisch eine Objektinstanz zugewiesen.

Zusaetzlich gibts dann noch Plugins (Behaviors), welche dir Aufgaben abnehmen, z.B. das automatische Befuellen von Create- und Update-Timestamps, Soft-Delete, I18N (so dass du z.B. eine Kategorie hast, den Titel aber in beliebig viele Sprachen hinterlegst), uvm.

Zusammen mit Symfony kommt dann hinzu, dass dir diese Model-Klassen automatisch generiert werden, genauso wie die Formulare zur Datenmanipulation. Du hast also sehr schnell dein Skeleton anhand dessen du die Applikation zusammenbaust. Ist ein sehr interessanter Ansatz

Greetz
alcaeus

Ok, das klingt wirklich nicht schlecht. Ich werde wohl erstmal bei meinem alten System bleiben, mir aber in den kommenden Monaten mal Doctrine/Symfony genauer angucken. Danke für die Erklärung.

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.