Hello,

Alle anderen Fehlermöglichkeitn1 sollten eigentlich auf einer tieferen Schicht schon abgefangen werden. Ich meine damit, dass kein Formularfeld einzeln auf dem Weg zum Server sauber herausgetrennt verloren gehen kann.

Ich verstehe ncht ganz was Du meinst. Dass alle Überprüfungen - wie z.B. ob die Eingabe im Feld Telefonnummern nur Zahlen enthält - am anfang der reservation.php durchgeführt werden? Und dies für alle Felder anstatt jedes Eingabefeld in einem anderen Teil des Skriptes zu überprüfen? War das so gemeint?

Nein, ich meinte die Prüfung, ob die Parameter überhaupt gesendet wurden.
Wenn Du ein Formular aufbaust, dass der Client sich per Request beschafft, kann er es sich ja auch zwischenspeichern, nach Belieben manipulieren und dann später erst in deiner persönlichen Variante benutzen. Das ist die Masche der Robots. Dabei lassen sie dann manchmal Felder aus dem Formular aus, weil sie "denken" dass diese für ihren Spam nicht relevant sind oder senden welche zurück, die (als Beispiel) einen Text "ich bin ein Spam-Robot" zugeordnet haben oder enthalten.

Es sollten am Server also immer alle erwarteten Parameterfelder erscheinen und alle logischen entsprechend ergänzt werden, falls dies nötig ist. Eine nicht geklickte Checkbox würde ja ggf. "false" bedeuten für den daran gbundenen Datenbank-Eintrag.

Daraus ergab sich meine These:
Dass auf dem Übertragungsweg nun ein Parameter nur teilweise übertragen wird, und daher Fehler verursacht, halte ich aufgrund der darunterliegenden Netzwerkschichten für nahezu unmöglich. Das dürfte nur durch gewollte Manipulation möglich sein.

Also langsam wirds mir zu kompliziert. Vorhin dachte ich noch ich häts verstanden, aber nun kommen langsam zuviele Fragezeichen auf. Das ist wohl doch bereits ein wenig zu komplex für ein Anfänger wie mich.

Du bist auch auf dem richtigen Weg.
Um Überprüfung kommst Du nicht herum, wie weit Du die treibst, ist Philosophie.

Mit einem entsprechenden "Pflichtarray" kannst Du diese ganze Überprüferei aber einer einzigen Funktion übertragen. Die kannst Du dann in jedem Projekt wiederverwenden.

Du müsstest dann nur das Array mit den Vorgaben jedes Mal befüllen.

#------

Um die Eigenschaften zu setzen, kannst Du Dir auch eine Wrapper-Funktion schreiben:

function set_css(&$_css, $elementtype, $elementname, $format, $value)
{
   $_css[$elementtype.'[name='.$elementname.']'][$format] = $value;
}

ok, ^^ das verstehe ich nun garnicht. Wo ist das nun einzuordnen?!

In der Abteilung "CSS für mein Formular" ;-)

Liebe Grüße aus Syburg bei Dortmund

Tom vom Berg

Hi,

<form action="<?php echo htmlspecialchars($_SERVER['PHP_SELF']); ?>" method="post">
htmlspecialchars() ist hier unnötig und $_SERVER['PHP_SELF'] ist manipulierbar.

Hmm, ich dachte gerade wenn es ja manipulierbar ist wäre htmlspecialchars angebracht? Was wäre denn an dieser Stelle besser? Direkt "reservierung.php" eingeben?

entweder das, oder wie in meinem Formular die sichere Server-Variable.

und die reservation.php:
warum eine Extra-Datei?

Hmm... Tom hat vorgeschlagen das HTML-Formular und das PHP-Skript strikt zu trennen. Ist doch auch sinnvoll, so kann ich das Formular includen und muss nicht alles per echo ausgeben lassen. Trägt doch zur Übersichtlickeit bei... was ist daran schlimm?

schlimm nicht direkt - ich finde die Aufteilung nur etwas unpraktsch. Wenn Du Dich auf

"trenne bitte als erstes HTML und PHP voneinander, soweit es geht."

beziehst, verstehe ich diesen Hinweis anders, nämlich so, dass Du Dich an das EVA-Prinzip halten solltest; also zunächst die PHP-Verarbeitung und hierin sämtliche Ausgaben _vorbereiten_, dann im HTML-Teil diese (möglichst ökonomisch) eintragen.

Das ganze Formular per echo auszugeben, fände ich auch unpraktisch. Ich finde, es kann ruhig immer, d.h. unabhängig von der Auswertung, angezeigt werden. Bei erfolgreichem Versand könnte man evtl. die Eingaben vorher löschen und wenn Du es in diesem Fall nicht mehr ausgeben willst, könntst Du auch den PHP-Bereich zwischendurch verlassen, um das Formular normal notieren zu können - ist zwar mMn unsauber, aber wenn man das nur einmal verwendet und übersichtlich notiert, noch akzeptabel.

freundliche Grüße
Ingo

Hello,

Hmm... Tom hat vorgeschlagen das HTML-Formular und das PHP-Skript strikt zu trennen. Ist doch auch sinnvoll, so kann ich das Formular includen und muss nicht alles per echo ausgeben lassen. Trägt doch zur Übersichtlickeit bei... was ist daran schlimm?

Ich halte das für eine saubere Arbeit auch für richtig.
So sind insbesondere bei größeren Projekten Markup, Anordnung der Elemente, Design und Backend nahezu voneinander getrennt und lassen sich einzeln entwickeln und testen.

Außerdem spart man sich bei Trennung die unbequemen und unübersichtlichen Escapes der Anführungszeichen für fast alle Situationen.

Liebe Grüße aus Syburg bei Dortmund

Tom vom Berg

Hi,

ist aber leider noch unschön und - was viel schlimmer ist - eine potentielle Spamschleuder.

<form action="<?php echo htmlspecialchars($_SERVER['PHP_SELF']); ?>" method="post">
htmlspecialchars() ist hier unnötig und $_SERVER['PHP_SELF'] ist manipulierbar.

das erste Zitat hat mit dem zweiten nichts zu tun.

Ich möchte nicht einfach behaupten, dass Du Unrecht hast. Ich habe das Thema aber ziemlich intensiv mit Christian Seiler durch und ich meine, er hatr Recht, wenn er sagt, dass

htmlspecialchars($_SERVER['PHP_SELF'])

nicht mehr manipulierbar für Cross-Site-Scripting ist.

da magst Du zwar recht haben, aber manipulierbar könnte es vielleicht doch sein, wenn auch nicht "entführbar". Bevor ich eine manipulierbare Server-Variable mit htmlspecialchars() behandle, nutze ich doch lieber die nicht-manilulierbare Variable "pur".

Naja, er könnte auch den Absatz mit in die Error-Ausgabe aufnehmen. Dann hat er aber im nackten HTML-Template keinen Hinweis auf das Markup. Das ist dann vollkommen dynamisch und damit fehlerträchtig.

Nunja, lieber fehlerträchtig als sinnloses Markup.

Aber auch eine Syntax-Prüfung der Telefonnummer wäre nicht verkehrt (und könnte auch den ein oder anderen Spam-Bot abhalten).

Da sehe ich aber schon wieder eine eine Einschränkung von Vanity-Nummern usw.

Es wird eine Telefonnummer gefragt, da erwarte ich dann auch eine und kein Rätselspiel. ;-)
Aber was meinst Du mit usw.?

freundliche Grüße
Ingo

Hi,

Was sind Replace Expressions?

eine Wortschöpfung von Dir. ;-)
Es gibt die einfache String-Ersetzung - die Funktion str_replace() und reguläre Ausdrücke - die Funktion preg_replace().

freundliche Grüße
Ingo

Hello Erich,

Im Prinzip wäre es schöner, wenn im HTML-Formular keinerlei Funktionen mehr stehen müssten, sondern nur noch Ausgaben von fertigen Variablen, aber dann müsstest Du den Kontrollfluss nochmal ändern, da ja bis zur letzten Zeile noch Änderungen am CSS-Array stattfinden könnten.

Klingt logisch. Danke

Das hat damit zu tun, dass sich für den weiteren Schritt zum absolut passiven Template Funktionen nur schlecht mit Replace oder regular Expressions ersetzen lassen. Aber das ist ja noch Zukunftsmusik...

Was sind Replace Expressions?

*gg* Die Wortschöpfung ist (siehe Ingo) zwar bisher noch nicht aufgetreten, aber sie ist eine logische  Zusammenziehung zweier Funktionalitäten, die es tatsächlich gibt ;-)

"Replace" steht hier für Ersetzung einer Zeichenkette.
"Expression" könnte dann die Kurzform für "Regular Expression", also für "Baumuster" stehen.

1:
    Und genau das soll ja im zweiten Fall passieren. Es sollen Zeichenketten,
    die einem bbestimmten Baumuster unterliegen, ersetzt werden.

2:
    Der einfachere Fall wäre, Zeichenketten, die genau mit dem Vergleichstyp
    übereinstimmen, zu ersetzen.

3:
    Der Dritte Fall wäre dann, Zeichenketten, die einem gewissen Muster entsprechen,
    zu extrahieren, nach bestimmten Regeln zu zerlegen, zu interpretieren und das
    Ergebnis wieder einzusetzen. Dann hättest Du im Prinzip einen eigenen Parser gebaut.

Beispiel zu 1:
--------------

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <title><!--{TITLE}--></title>
  <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
  <style type="text/css">
    body
    {
      font-family:century gothic, tahoma, arial,sans-serif;
      font-size: 0.8em;
    }

div
    {
      display:table; /* Inhaltsbreite  (zumindest in Gecko) */
    }

* html div, * html ul
    {
       height:1%;  /* notwendiges hasLayout für IE 6 */
    }

</style>
  <!--{CSS-general}-->
  <!--{CSS-particular}-->
</head>
    <body>
        <!--{BODY-above}-->
        <!--{BODY-content}-->
        <!--{BODY-beneath}-->
    </body>
</html>

So könnte nun so ein stark reduziertes passives template aussehen.
Es fehlen hier noch die ganzen statischen Bereiche, di in jeder Seite des Webauftrittes vorhanden wären, aber ich bin kein Designer und daher ideenlos ;-)

Ersetzt werden können nun die Zeichenketten

<!--{TITLE}-->
    <!--{CSS-general}-->
    <!--{CSS-particular}-->
    <!--{BODY-above}-->
    <!--{BODY-content}-->
    <!--{BODY-beneath}-->

Diese Zeichenketten können von PHP eindeutig erkannt werden und daher genau ersetzt werden durch einen einfachen str_replace-Befehl http://www.php.net/manual/en/function.str-replace.php

Wenn eine dieser Zeichenketten nicht erstzt wird, macht es für das HTML nichts aus, da sie als gültige HTML-Kommentare notiert sind.

Befinden sich in Deinem "Wertevorrat" des PHP-Teiles Deiner Applikation nun die passenden Erstzungsn dafür, dann können diese durchgeführt werden. Sind keine Elemente zu den vorhandenen Bezeichnern in Deiner Liste vorhanden, bleiben die übrigen Bezeichner als HTML-Kommentare erhalten

Du könntest das template einem User zur Verfügung stellen, und ihm gestatten, dass er "seine Seite" personalisiert gestaltet, ohne dass er dadurch über PHP-Inliene-Statements Zugriff auf Deinen Webserver erhalten könnte, denn die werden ja bei einem einfachen Replace gar nicht mehr ausgewertet.

Beispiel zu 2:
--------------

Es gilt das gleiche Template.
Dir gefällt es aber nicht, dass Platzhalter erhalten bleiben, weil z.B. nicht alle User dieselben zur Verfügung haben und daher nicht immer alle ausgetauscht werden von Deinem System.

Dann kannst Du den Weg anders herum gehen.

Statt dass Du Deinen Wertevorrat abarbeitest und danach suchst, ob sich ein passener Bezeichner zur Ersetzung im Template befindet, kannst Du auch alle Bezeichner aus dem Template heraussuchen und sie dann durch einen eventuell vorhandenen Inhalt aus Deinem Wertevorrat ersetzen oder gegen nichts.

Dazu benötigst Du dann ein universelles Suchmuster. Das Arbeiten mit regular Expressions bietet sich hier an.

Ein Pattern (ein Muster) dafür könnte in unserem Fall so aussehen

$pattern = '~<!--{[A-Z]+(-[a-z]+)?}-->~';

Mit diesem kleinen Script kannst Du die dann finden:

<?php   ### parse-template.php ###

$pattern = '~<!--{[A-Z]+(-[a-z]+)?}-->~';

$template = file_get_contents('template01.html');

$_matches = array();

echo preg_match_all($pattern, $template, $_matches);
        // alternativ:
        # echo preg_match_all($pattern, $template, $_matches,PREG_SET_ORDER | PREG_OFFSET_CAPTURE);

echo "<pre>\r\n";
        echo htmlspecialchars($template) . "\r\n\r\n";

echo htmlspecialchars(print_r($_matches,1));
        echo "</pre>\r\n";

?>

Die Ausgabe sollte ergeben:

Array
    (
        [0] => Array
            (
                [0] => <!--{TITLE}-->
                [1] => <!--{CSS-general}-->
                [2] => <!--{CSS-particular}-->
                [3] => <!--{BODY-above}-->
                [4] => <!--{BODY-content}-->
                [5] => <!--{BODY-beneath}-->
            )

[1] => Array
            (
                [0] =>
                [1] => -general
                [2] => -particular
                [3] => -above
                [4] => -content
                [5] => -beneath
            )

)

Mit einer normalen str_replace()-Anweisung kannst Du die gefundenen dann ersetzen.
http://www.php.net/manual/en/function.str-replace.php

Dazu kannst Du Dir anhand des Treffer-Arrays und deines Wertevorrat-Arrays ein Ersetzungsarray aufbauen und dann das Treffer-Array und das Ersetzungs-Array an str_replace() übergeben.

Alle Treffer, die keine Ersetzung erhalten sollen, haben im Ersetzungsarray nur einen 'false'- oder ''-Eintrag.

Oder aber Du benutzt str_replace in einer eigenen Schleife, und ersetzt eben alle Treffer, für die es Einträge in deinem Wertevorrat gibt gegen den Wert und alle anderen gegen '', was aber wesentlich langsamer ist.

Oder Du erstezt gleich alle mit preg_replace() in einer Schleife.

Beispiel zu 3:
--------------

Wie ich im zweiten Beispiel schon angedeutet habe, kann man die Platzhalter auch in Gruppen teilen und ihnen so noch weitere "Verhaltensweisen" mitgeben. Durch den Aufbau des Patterns für preg_match_all() ist es möglich, diese Informationen zu separieren.

Diese könntest Du dann durch eine eigene Funktion schicken und entsprechend der zusätzlichen Informationen auswerten lassen.
Hier würde mir "Überladung" als Stichwort einfallen.

Damit wärest Du dann bei einer intelligenten Template-Engine angekommen.

So ein Pattern könnte dann z.B. so aussehen:

<!--{ T-bezeichner }-->
     <!--{ F-Funktionsname ( Argumente ) }-->
     <!--{ M-Menuname ( Argumente ) }-->

und ein Pattern dafür:

$pattern = '=^(.*?)(?:<!--\{)\s{0,}(H|L|M|F|T)-([a-z0-9]{1,})(?:\s{0,}'.
               '\(([a-z0-9-+\*/, ].*?)\s{0,}\))?\s{0,}(?:[^\}]*?)(?:\}-->)(.*$)=msi';

mit z.B. folgenden Bedeutungen

- T Texte aus der Content-Datei

- Z Zentrale Texte aus .ht_commom_content im Verzeichnis.ht_include

rekursive Auflösung von

- S Subtemplate aus demselben Verzeichnis, wie das Template

- M Common Subtemplate (z.B. Menu) aus dem Verzeichnis .ht_common_templates

#     wird rekursiv aufgelöst

- F Funktionen, definiert in functions.inc.php und freigegeben in config.inc.php

- H Headerdaten

- L Linktexte

Wie komplex Du as machst, ist Dir überlassen.

Abschließend will ich noch bemerken, dass das Ganze (oder die Stufe 2) dann auch rekursiv, bzw. zyklisch auf das Template wirken kann. Solange also Patterns gefunden werden, werden diese ersetzt. Du kannst also durch wiedereinsetzen von Patterns im nächsten Parse-Durchlauf dafür sorgen, dass diese wieder ersetzt werden. Dabei musst Du nur aufpassen, dass Du keine Patterns einsetzt, die Du schon ersetzt hattest. Dann würdest Du ggf. eine Endlosschliefe bauen.

Am einfachsten ist es, sich ein Array mitzuschreiben, welche Patterns man innerhalb eine Stufe schon ersetzt hat. Die darf man dann i.d.R. in tieferen Stufen nicht wieder einsetzen.

Es wäre dadruch also z.B. möglich, mit einem Standard-Template und der Anweisung "Hole Datensatz aus Datenbank und setze 'hole nächsten bis eof' wieder als Pattern ein" eine äußerst flexible HTML-Seite aufzubauen...

Das sind alles nur Anregungen, um zu verstehen, wie man "Web-2.0"-Template-Engines bauen kann und welche Stufen es dabei gibt. Sicherlich habe ich mindstsns die Hälfte vergessen und es gibt hier Leute, die das konstruktiv ergänzen können :-)

Liebe Grüße aus Syburg bei Dortmund

Tom vom Berg