Anregungen zu PHP und OR-Mapping: Teil 1: Daten-Objekte - Seite 2

Chriz · 14.09.2009, 17:39

Zum letzten Punkt von dir nikosch: Man könnte darüber nachdenken, getNicknameRaw() bzw. getBirthDateRaw() einzuführen. Zu Phoscur: Ich mache mir darüber mal Gedanken und poste heute Abend was dazu. Danke euch dreien auf jeden Fall schonmal für eure Einwände!

nikosch · 14.09.2009, 17:43

Zitat:

Man könnte darüber nachdenken, getNicknameRaw() bzw. getBirthDateRaw() einzuführen.

Nicht schlecht. Vielleicht noch einen Filter vorschalten (man muß ja nicht jede 10k-Eingabe und XSS-Versuche in den Nickname schreiben), dann passt das schon fast. Vielleicht könnte man das Prinzip auch gleich für Defaultangaben ausweiten.

Chriz · 14.09.2009, 18:05

Ich muss wieder widersprechen, XSS-Filterung ist nicht die Aufgabe der Daten-Klasse, sondern des Views oder der Entsprechung für das Ausgabemedium.
Default-Angaben müssten wahrscheinlich genauso wie die ValidateFilter gesetzt werden.

nikosch · 14.09.2009, 18:12

Ich meine nicht htmlspecialchars oder dergl.
Sondern eher eine Art Intrusion detection. 10k Zeichen in einem Namensfeld, <script> in einem Altersfeld, Arrays aus einer Inputangabe. Das sind Sachen, die kann man im Vorfeld aussieben und muß sie nicht mal raw ins Objekt schreiben. Klar, man kann sie auch im Vorfeld als Manipulationsversuch komplett ablehnen.
Langsam überlege ich, ob es nicht doch besser ist, für einen Formularinput ein extra Objekt zu führen. Schließlich kann ein Forminput ja theoretisch durchaus auch mehrere Domainobjekte bedienen.
Bleibt dann aber die Frage, wohin die Validierung gehört.

Chriz · 14.09.2009, 19:13

Zitat:

Zitat von nikosch

Ich meine nicht htmlspecialchars oder dergl.
Sondern eher eine Art Intrusion detection. 10k Zeichen in einem Namensfeld, <script> in einem Altersfeld, Arrays aus einer Inputangabe. Das sind Sachen, die kann man im Vorfeld aussieben und muß sie nicht mal raw ins Objekt schreiben. Klar, man kann sie auch im Vorfeld als Manipulationsversuch komplett ablehnen.

Die eierlegende Wollmilchsau soll ja vermieden werden. Das Daten-Objekt kennt das Ausgabemedium immernoch nicht

Die Daten könnten ja auch im PDF und/oder in der DB landen, soll dagegen dann auch abgesichert werden? Darum ist einzig die Klasse, die das Ausgabemedium (HTML, Datenbank, CSV, PDF, Email, ..) verwaltet zuständig, die zur Verfügung gestellten Daten abzusichern. Ob das jetzt komfortabel für den Anwender (also dem Programmierer, der diese Klasse verwendet) ist, ist eine andere Sache. Ich will damit nicht sagen, dass ich den Komfort des Anwenders ignoriere oder als zweitrangig einstufe, nur muss dafür eben an anderer Stelle eine Lösung gefunden werden.

Zitat:

Zitat von nikosch

Langsam überlege ich, ob es nicht doch besser ist, für einen Formularinput ein extra Objekt zu führen. Schließlich kann ein Forminput ja theoretisch durchaus auch mehrere Domainobjekte bedienen.
Bleibt dann aber die Frage, wohin die Validierung gehört.

Kann man tun. Ich finde hier muss man doch nur etwas kreativ sein und die Klasse richtig zu gebrauchen wissen. Wenn ich mir eine abstrakte Formular-Klasse baue, kann ich durchaus recht komfortabel ein Formular erstellen. Es kommt eben darauf an, wem ich welche Kompetenzen zuspreche.

PHP-Code:

  <?php
// registration form
$form = new Anti_Form_User();
$form->addUserElement("nickname");
$form->addUserElement("birthDate");
// ..
$form->addCustomElement("newsletter", new Anti_ValidateFilter_Bool());
if ($form->isValid($_POST)) {
  $user = $form->getUser();
  $userManager = new Anti_User_Manager(..);
  $userManager->save($user);
  if ($form->getValue("newsletter")) {
    $newsletterManager = new Anti_Newsletter_Manager();
    $newsletter->addEmail($user->getEmail());
  }
  // goto login.php
}
?>
// ..
<input type="text" name="nickname" value="<?php echo htmlspecialchars($form->getValueRaw("nickname")) ?>" />
// ..
<input type="hidden" name="newsletter" value="0" />
<input type="checkbox" name="newsletter" value="1" />
Newsletter abonnieren?

(als Beispiel)

Steve · 14.09.2009, 19:29

Zitat:

Zitat von Chriz

Wo sind sie denn noch unterschiedlich? Beim Datum, und hier habe ich ja ein normalisiertes, universelles Format gewählt: die DateTime-Klasse.

Oh, sorry habe nicht so genau hingesehen (war ja auch eine Menge Text)

Ok, dann weitere Beispiele, die mir so spontan einfallen:

Float: Punkt oder Komma als Dezimaltrennzeichen
BOOLEAN: 0/1 aber auch true/false
NULL: PHP-NULL (null), MySQL-NULL ('NULL'), XML-NULL(null="true" und Leerstring?)

Mir schwebte mal eine Konverter-Klasse vor, die die Datentypen auf ein festgelegtes einheitliches Referenz-Format konvertiert und jeweils Regeln zur Umwandlung von Quell- auf Ziel-Format besitzt. Intern wird dann immer zuerst auf das Referenz-Format konvertiert umd die Regelmengen klein halten zu können.

Ok, das ist jetzt vielleicht sehr speziell, ich benötige soetwas aber öfter für den Im-/Export für (CSV, EXCEL, MySQL, XML).

nikosch · 14.09.2009, 19:59

Zitat:

Ich will damit nicht sagen, dass ich den Komfort des Anwenders ignoriere oder als zweitrangig einstufe, nur muss dafür eben an anderer Stelle eine Lösung gefunden werden.

Was aber letzten Endes irgendwo auf eine doppelte Datenhaltung hinausliefe. Und/oder auf eine doppelte Validierung. Womit sich mir immer mehr die Fraghe stellt, ob eine Validierung im User-Objekt dann überhaupt noch gerechtfertigt ist oder ob nicht viel mehr das Userobjekt erst dann erstellt werden sollte, wenn eine vollständig ausreichende und positiv validierte Datenbasis vorliegt. Was wiederum Probleme mit dem Punkt "nur das Userobjekt weiß, was es braucht" mit sich bringt. Damit wäre die Quintessenz:

PHP-Code:

  $nickname = $_POST["nickname"];
$birthDate = $_POST["birthDate"];

$user = new User();
$formdata = new FormDataContainer;
$formdata->addNamespace ('User');

$formdata->add('User' , 'nickname' , $nickname , $user->isValidNickname($nickname));
$formdata->add('User' , 'birthDate' , $birthDate , $user->isValidBirthDate($birthDate));

// more

/* 
Alternativ vielleicht Userobjekt + callback
Frage wäre dann, wie Property-Abhängigkeiten zu lösen wären:

$formdata->add('birthDate' , $birthDate , array ($user , 'isValidBirthDate'));
*/
 

if ($formdata->isValid ()) { // durchläuft alle Settings
  $user->setAssocData ($formdata);
  }
else {
  // rewrite Form
  }

oder ähnlich, wobei sich Userproperties auch nich sinnvoll bei der Validierung verknüpfen ließen.

Chriz · 14.09.2009, 20:33

@Steve:
Also wie gesagt, im Daten-Objekt sollten die Daten normiert vorliegen, bei Fließkommawerten also als PHP-float/double, bei boolschen Werten eben als PHP-bool und bei NULL eben auch NULL. Ich denke da sind wir uns einig, denn nur so kann ich sie auch wieder einfach in alle anderen Formate exportieren, ohne für jede Kombination Import/Export-Konverter schreiben zu müssen. Der Punkt denn du anführst, dass die Datenquelle sich natürlich unterscheiden kann/wird/darf ist richtig.

Mein Vorschlag von vorhin, die ValidateFilter auf public zu setzen ist dagegen doch kein so guter. Ich möchte nicht, dass es möglich ist im Nicknamen DateTime-Objekte unterzubringen oder im Geburtsdatum plötzlich Unix-Zeitstempel zu jonglieren. Das muss fest sein. Andernfalls ist mein User-Objekt nicht mehr verlässlich, sonst könnte ich aus dem User-Objekt auch ein News-Objekt on-the-fly machen, wenn ich lustig bin.

Die Daten-Klasse kann darum die Informationen darüber, ob ein Excel-Feld leer ist und deshalb einen md5(null) (erfunden) zurückliefert, nicht kennen, sie kann nicht wissen dass INI "on"/"off" als boolsche Werte betrachtet oder in der Custom-CSV-Datei "no" und "nein" das selbe sind. Wer das weiß, ist die Datenquelle (bei mir der Manager - Kapitel 3

). Das Formular weiß z.B. anhand eines Localization-Objektes/der Konfiguration/Programmierung, in welchem Datumsformat die Eingabe zu erwarten ist. Der CSV-Manager weiß, dass "yes" bool(true) bedeutet oder alle Werte kleiner 0 z.B. NULL zu sein haben (warum auch immer), weil er seine Datengrundlage kennt. Also ist diese Klasse auch dafür zuständig, die Daten so umzuwandeln, dass die Daten-Klasse sie versteht. Dafür haben wir ja unsere unabhängigen ValidateFilter-Klassen, die jeder verwenden oder erweitern kann. Die Verwendung ist ja nicht nur auf die Daten-Klasse beschränkt.

Es ist aber wahr, dass dadurch eine dreifache Validierung/Filterung stattfinden könnte: Import -> Daten-Klasse -> Export.

Formular-Klasse muss deutsches Datum in universelles String-Format bringen,
Daten-Klasse muss universelles String-Format in DateTime-Objekt drücken
Datenbank-Klasse muss DateTime in Unix-Zeitstempel umwandeln

Aber es ist doch trotzdem sauber und gerechtfertigt zwischen Import und Export einen Vermittler einzusetzen, der die ganzen Daten erstmal normiert speichert. So weiß Import und Export jeweils was zu tun ist, ohne sich gegenseitig kennen zu müssen. So kann ich ein User-Objekt aus der Session genauso behandeln wie den Admin aus dem festen Konfig-File (damit er nicht gelöscht werden kann) und die übrigen User aus der Datenbank. Und zwar garantiert gleich, denn sonst würde die Daten-Klasse ja vorher moppern

Steve · 14.09.2009, 21:14

Hi Chriz,

danke für deine detaillierten Ausführungen. Ich merke, da hat jemand in etwa die selben Anforderungen/Problematiken für den Datenaustausch erkannt

Ich denke also, wir sind uns 100%-ig einig.
Als Referenz-Datentyp (Normierung) den PHP-Datentyp zu benutzen ist nur konsequent. Eventuell würde ich bei der DateTime-Klasse schon auf ein festes Format bestehen.

Ok, dann habe ich hier vielleicht schon etwas vorweggegriffen, worauf du im "Manager - Kapitel 3" erst eingehen wolltest. Klingt interessant - ich bin gespannt.

Chriz · 14.09.2009, 21:53

Zitat:

Zitat von Steve

Als Referenz-Datentyp (Normierung) den PHP-Datentyp zu benutzen ist nur konsequent. Eventuell würde ich bei der DateTime-Klasse schon auf ein festes Format bestehen.

Naja, jeder brauch ein anderes, da fand ich DateTime naheliegend. Aber eigentlich ist es egal in welchem Format.

Danke dir auf jeden Fall fürs Beteiligen hier im Thread. Ich hoffe ich kam nicht stur rüber, war lediglich in einigen Bereichen von meiner Meinung überzeugt. Ist ja wie gesagt nur eine Idee oder ein Ansatz und keine Best-Practice. Da gibts andere die das von ihren Ideen behaupten dürfen.

Themen-Optionen
Druckbare Version zeigen Jemanden per E-Mail auf dieses Thema hinweisen
Thema bewerten
Thema bewerten:

Ähnliche Themen
Thema	Autor	Forum	Antworten	Letzter Beitrag
Registrierte User sollen ihre Daten ändern können	54ch4	PHP Tipps 2009	17	14.03.2009 14:29
Mehrere Arrays unterschiedlicher Größe kombinieren	querfisch	PHP Tipps 2007	9	31.03.2007 21:34
Session Frage - gleiches Formular 2 mal alle Daten behalten	NetLook	PHP Tipps 2007	1	21.11.2005 18:42
PHP-GTK Tutorial		Beitragsarchiv	9	02.11.2005 21:07
[Erledigt] sql daten für einen kunden auslesen/ändern im Formular		PHP Tipps 2005-2	3	12.10.2005 08:36
[Erledigt] Daten auslesen und ändern		Datenbanken	2	17.09.2005 19:28
Daten eintragen und auslesen	Rettungsdackel	Datenbanken	0	14.09.2005 16:29
Daten in Datenbank ändern		PHP Tipps 2005	3	27.01.2005 14:40
array_push nur in begrenzter Anzahl ausführen ?		PHP Tipps 2004	2	07.09.2004 09:05

14.09.2009, 17:39
Chriz Moderator Registriert seit: 11.05.2008 Beiträge: 6.069	Zum letzten Punkt von dir nikosch: Man könnte darüber nachdenken, getNicknameRaw() bzw. getBirthDateRaw() einzuführen. Zu Phoscur: Ich mache mir darüber mal Gedanken und poste heute Abend was dazu. Danke euch dreien auf jeden Fall schonmal für eure Einwände! __________________ "Nuschel ich?" - "Was?"


Mister Ad PHP Code Flüsterer Registriert seit: 21.08.2005 Beiträge: 4682 PHP-Kenntnisse: Fortgeschritten

14.09.2009, 18:05
Chriz Moderator Registriert seit: 11.05.2008 Beiträge: 6.069	Ich muss wieder widersprechen, XSS-Filterung ist nicht die Aufgabe der Daten-Klasse, sondern des Views oder der Entsprechung für das Ausgabemedium. Default-Angaben müssten wahrscheinlich genauso wie die ValidateFilter gesetzt werden. __________________ "Nuschel ich?" - "Was?"

14.09.2009, 18:12
nikosch moderatives Dielektrikum Registriert seit: 21.05.2008 Beiträge: 34.256 PHP-Kenntnisse: Fortgeschritten	Ich meine nicht htmlspecialchars oder dergl. Sondern eher eine Art Intrusion detection. 10k Zeichen in einem Namensfeld, <script> in einem Altersfeld, Arrays aus einer Inputangabe. Das sind Sachen, die kann man im Vorfeld aussieben und muß sie nicht mal raw ins Objekt schreiben. Klar, man kann sie auch im Vorfeld als Manipulationsversuch komplett ablehnen. Langsam überlege ich, ob es nicht doch besser ist, für einen Formularinput ein extra Objekt zu führen. Schließlich kann ein Forminput ja theoretisch durchaus auch mehrere Domainobjekte bedienen. Bleibt dann aber die Frage, wohin die Validierung gehört. __________________ -- One pixel is still too big. Please make it smaller. ASAP. Initiative Mittelstand. Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers. --

14.09.2009, 20:33
Chriz Moderator Registriert seit: 11.05.2008 Beiträge: 6.069	@Steve: Also wie gesagt, im Daten-Objekt sollten die Daten normiert vorliegen, bei Fließkommawerten also als PHP-float/double, bei boolschen Werten eben als PHP-bool und bei NULL eben auch NULL. Ich denke da sind wir uns einig, denn nur so kann ich sie auch wieder einfach in alle anderen Formate exportieren, ohne für jede Kombination Import/Export-Konverter schreiben zu müssen. Der Punkt denn du anführst, dass die Datenquelle sich natürlich unterscheiden kann/wird/darf ist richtig. Mein Vorschlag von vorhin, die ValidateFilter auf public zu setzen ist dagegen doch kein so guter. Ich möchte nicht, dass es möglich ist im Nicknamen DateTime-Objekte unterzubringen oder im Geburtsdatum plötzlich Unix-Zeitstempel zu jonglieren. Das muss fest sein. Andernfalls ist mein User-Objekt nicht mehr verlässlich, sonst könnte ich aus dem User-Objekt auch ein News-Objekt on-the-fly machen, wenn ich lustig bin. Die Daten-Klasse kann darum die Informationen darüber, ob ein Excel-Feld leer ist und deshalb einen md5(null) (erfunden) zurückliefert, nicht kennen, sie kann nicht wissen dass INI "on"/"off" als boolsche Werte betrachtet oder in der Custom-CSV-Datei "no" und "nein" das selbe sind. Wer das weiß, ist die Datenquelle (bei mir der Manager - Kapitel 3 ). Das Formular weiß z.B. anhand eines Localization-Objektes/der Konfiguration/Programmierung, in welchem Datumsformat die Eingabe zu erwarten ist. Der CSV-Manager weiß, dass "yes" bool(true) bedeutet oder alle Werte kleiner 0 z.B. NULL zu sein haben (warum auch immer), weil er seine Datengrundlage kennt. Also ist diese Klasse auch dafür zuständig, die Daten so umzuwandeln, dass die Daten-Klasse sie versteht. Dafür haben wir ja unsere unabhängigen ValidateFilter-Klassen, die jeder verwenden oder erweitern kann. Die Verwendung ist ja nicht nur auf die Daten-Klasse beschränkt. Es ist aber wahr, dass dadurch eine dreifache Validierung/Filterung stattfinden könnte: Import -> Daten-Klasse -> Export. Formular-Klasse muss deutsches Datum in universelles String-Format bringen, Daten-Klasse muss universelles String-Format in DateTime-Objekt drücken Datenbank-Klasse muss DateTime in Unix-Zeitstempel umwandeln Aber es ist doch trotzdem sauber und gerechtfertigt zwischen Import und Export einen Vermittler einzusetzen, der die ganzen Daten erstmal normiert speichert. So weiß Import und Export jeweils was zu tun ist, ohne sich gegenseitig kennen zu müssen. So kann ich ein User-Objekt aus der Session genauso behandeln wie den Admin aus dem festen Konfig-File (damit er nicht gelöscht werden kann) und die übrigen User aus der Datenbank. Und zwar garantiert gleich, denn sonst würde die Daten-Klasse ja vorher moppern __________________ "Nuschel ich?" - "Was?" Geändert von Chriz (14.09.2009 um 20:37 Uhr).

14.09.2009, 21:14
Steve Erfahrener Benutzer Registriert seit: 28.08.2009 Beiträge: 233 PHP-Kenntnisse: Anfänger	Hi Chriz, danke für deine detaillierten Ausführungen. Ich merke, da hat jemand in etwa die selben Anforderungen/Problematiken für den Datenaustausch erkannt Ich denke also, wir sind uns 100%-ig einig. Als Referenz-Datentyp (Normierung) den PHP-Datentyp zu benutzen ist nur konsequent. Eventuell würde ich bei der DateTime-Klasse schon auf ein festes Format bestehen. Ok, dann habe ich hier vielleicht schon etwas vorweggegriffen, worauf du im "Manager - Kapitel 3" erst eingehen wolltest. Klingt interessant - ich bin gespannt.