uploader anpassen

[dedlfix]

Tach!

Du schreibst jede Menge HTML-Code in Dein PHP-Script. Im Moment mag das noch eine sinnvolle Vorgehensweise für Dich sein, insbesondere, wenn Du alles schön "griffig" in einer einzigen PHP-Datei haben willst. Später wirst Du allerdings bei größeren Projekten schnell merken, dass Dir eine strengere Trennung von Programm-Logik (PHP) und Ausgabeformat (HTML) wesentlich mehr Übersichtlichkeit in Dein Projekt bringen kann.

Einspruch. Das geht vielleicht bei einfachen Templates mit nur einer Handvoll zu ersetzender Werte gut. Aber irgendwann kommt Logik mit ins Spiel. Beispielsweise soll die Auflistung der Fehlermeldungen nur dann angezeigt werden, wenn es welche gibt. Die Anzahl der Datensätze aus dem DBMS ist dem Template-Ersteller nicht bekannt. Schlimmer noch, sie ist variabel. Man benötigt da also eine Schleifenkonstruktion, um alle zu berücksichtigen. Eine Antwort auf solche Szenarien sind Blöcke, die man gezielt aufnehmen oder weglassen kann. Dann ist man bei reinen HTML-Templates schnell bei einer mehr oder weniger komplexen Hilfssysntax, und einem ebensolchen System, das diese auswerten kann. Das kann man so machen, und da gibts auch vorgefertigte Systeme.

Einfacher ist es, nicht PHP und HTML zu trennen, sondern Verarbeitungslogik von Darstellungslogik. Das Darstellungslogik kann dann wie der Rest des Systems PHP verwenden, was ja bereits selbst eine Template-Sprache ist. Der Fehlermeldungsblock kann zum Beispiel so notiert werden:

<?php if ($errors): ?>  
<ul>  
  <?php foreach($errors as $error): ?>  
  <li><?= htmlspecialchars($error) ?></li>  
  <?php endforeach ?>  
</ul>  
<?php endif ?>

Der Code geht von PHP 5.4 aus, in dem <?= als Kurzform für <?php echo unausschaltbar enthalten ist. Wenn man der eigenen Herr über die Anwendung und dem Konfigurationswert short_open_tag ist und keine Kompatibilität mit anderen nicht beeinflussbaren Einstellungen benötigt, kann man auch noch die <?php zu <? abkürzen.

$search = sprintf('{%s}', $key);
    $html_form = str_replace(
        $search,
        htmlspecialchars($value),
        $html_form
    );

sprintf() bringt hier keinen wirklichen Vorteil. Eine Klammer vor und nach einem Wert zu setzen, geht vergleichsweise übersichtlich und einfach in der Stringverkettungssyntax ... str_replace('{' . $key . '}', htmlspecialchars( ...

Eine wasserdichte Fehlerprüfung solltest Du unbedingt auch implementieren. In meinem Code-Beispiel wird nicht sichergestellt, dass $_GET['s_id'] zwingend vorhanden sein muss, es wird im Fehlerfalle mit einem Leerstring weitergearbeitet.

Genauer: null (was im String-Kontext zu einem Leerstring wird) und eine normalerweise unterdrückte Notice-Meldung. Dise Notice-Meldungen sind aber ein wichtiges Hilfsmittel beim Entwickeln der Anwendung, zeigen sie einem doch, wo man auf etwas zuzugreifen versucht, was gar nicht da ist. Das kann durchaus ein Fehler und nicht immer gewolltes Verhalten sein. Deshalb empfiehlt es sich, mit auf E_ALL gestelltem error_reporting zu entwickeln und allen Notice-Meldungen auf den Grund zu gehen.

copy(“$tempname”, “$name”);
Was ist hier der Unterschied zu copy($tempname, $name)? Lass die Anführungszeichen weg, sie machen nichts besser,

Zumal das auch noch typografische Anführungszeichen und nicht die benötigten " sind.

Daher ergibt sich folgender Einzeiler für Deinen originalen Vierzeiler:

Der dann allerdings wieder zu einem Mehrzeiler ergänzt werden muss, wenn man Fehlerzustände ordentlich abfangen will.

dedlfix.