Fragen zur Roadmap (Filter Class, DB Class)

[k00ni]

Hallo,
ich wollte wissen, was bei der Roadmap mit Filter Class und DB Class gemeint ist.
Unter DB Class stelle ich mir vor, dass du eine Klasse schreiben willst, damit deine Skripte auf verschiedenen RDBMS laufen und dass der Zugriff auf die Datenbank \"geregelt\" stattfindet.
Was aber meinst du genau mit Filter Class?
 
Grüße

[Powie]

DB Class: Die Klasse versuche ich gerade umzusetzen, um das pSys auch für DB2 nutzbar zu machen. Kostet etwas Arbeit, da DB2 keine LIMIT Statements im SQL kennt sondern mit Partitionierung arbeitet. Diesen Teil will ich dann vor allem über die Klasse lösen um zu sparen extra SQL Statements für DB2 schreiben zu müssen.
Filter Class: Die Idee kam mir bei Ansicht einer ganz anderen Geschichte, ich plane eine Class aufzusetzen die mir alle Eingaben die über get / post /etc kommen entsprechend einfach filterbar zu machen. Der Ansatz war mit den filter Funktionen in php5 ja da, aber da dies sehr umfangreich ist möcht ich mir das vereinfachen... Benötige ich dann ebenfalls für die DB Class zum Filtern der Statements.

[k00ni]

Zur DB Class: Da kannste gerne meine Funktion mit dem Prepared Statement nutzen, wenn es in dein Konzept passt. Weiterhin würde ich die \"Säuberung\" der Statements in einer extra Klasse auslagern; welche zwar an sich eigenständig ist, aber trotzdem in der Db Class fest verwendet wird.
Die Klasse für die \"Datenbank\"-Sicherheit sollte folgendes bieten:
- Statement wird als Prepared Statement abgesetzt
- Maskierung bzw. Anpassung aller übergebenen Variablen
Damit hällst du eigentlich alles raus, was Ärger machen könnte. Wüsste jetzt nicht, wie man dort noch die Datenbank über diesen Weg kompromitieren könnte.
 
Zur Filter Class: Verkalkuiere dich nicht mit dem Maskieren, Abfragen und Anpassen aller durch GET / POST / SESSION /... übergebenen Variablen. Ich könnte mir vorstellen, dass das unnötig in die Performance gehen kann.
Gut wäre eine Trennung der Bereiche (einer für GET, einer für POST ...) , dass ich bei der Verwendung von GET - Variablen, ein einfaches $Filter_Class=>Clean_GET (); aufrufen kann und alle sind gecleant. Dabei sollte ich die Säuberung präzisieren können, denn man stelle sich vor, man möchte mit HTML-Code arbeiten, nur geht das nicht, da dieser immer maskiert wird.

Gut wäre eine Trennung der Bereiche (einer für GET, einer für POST ...) , dass ich bei der Verwendung von GET - Variablen, ein einfaches $Filter_Class=>Clean_GET (); aufrufen kann und alle sind gecleant. Dabei sollte ich die Säuberung präzisieren können, denn man stelle sich vor, man möchte mit HTML-Code arbeiten, nur geht das nicht, da dieser immer maskiert wird.[/quote]
 
Säubern funktioniert nicht. Lieber einen Fehler werfen wenn illegale Daten übergeben werden.

- Maskierung bzw. Anpassung aller übergebenen Variablen[/quote]
Dito.

[Powie]

Zur Filter Class: Verkalkuiere dich nicht mit dem Maskieren, Abfragen und Anpassen aller durch GET / POST / SESSION /... übergebenen Variablen. Ich könnte mir vorstellen, dass das unnötig in die Performance gehen kann.[/quote]
Ich denke das ist auch gar nicht notwendig alle übergebenen Daten sofort zu filtern. Die Gefahr besteht ja erst bei deren Nutzung. Zudem ist das teilweise gar nicht möglich, da ich ja die Daten unterschiedlich behandeln muss, je nachdem was ich damit mache. Das sieht man sehr gut wenn man sich dies mal anhand eines Postings im Forum veranschaulicht. Das muss teilweise in 3 Varianten bearbeitet werden.
1. für die HTML Ausgabe
2. für die SQL Query
3. für die Übergabe an weitere Funktionen.
Deshalb: Filtern an der Stelle wo die Daten verarbeitet werden.

[k00ni]

In dem Zusammenhang würde ich auch über eine Fehlerbehandlung nachdenken. Da es denke ich, eh nur für PHP 5.x und höher entwickelt wird, könnte man ja dort das Exception-System von PHP nutzen. Muss ja keine goße Sache sein.
 

$error_text =  $text;
}
function set_Errornumber ( $number )
{
$this->$error_number =  $number;
}
}
?>

 
 
Nicht schlagen, ist nur ein Entwurf, den ich grad runtergetippt habe. Man könnte das als Mutterklase nehmen und dann für SQL, Dateioperationen oder allgemeine Dinge noch präzisieren (neue Klassen ableiten).
Zudem könnte man noch eine Liste anlegen, wo man einer Fehlernummer ein bestimmten Fehlertext zuordnet. Wobei dass aber nur als nettes Gimmick zählt und nicht essentiell wichtig ist.
Weitere Gedanken dazu?

[k00ni]

Gibt es hier bereits ersten Code, den man sich anschauen kann?
Zur DB Class: Wenn du dich um die DB2 Implementierung kümmerst Powie, könnten wir uns um die MySQL-Umsetzung kümmern. Nur dazu fehlt halt ein Grundgerüst oder eine (grobe) Beschreibung, wie du die Klasse strukturieren möchtest.
Ich weiß nicht, ob ich dich da richtig verstanden hatte: Möchtest du sämtliche DB-Arbeit in dieser Klasse kapseln? Wenn ja, dann wäre ich da nicht dafür, sondern würde für jede Abfrage eine eigene Funktion schreiben. Dies setzen wir gerade sehr erfolgreich ein und es erhöht u.a. die Wiederverwendbarkeit. Ich da lieber Funktionen alá \"Absetzen einer Abfrage\", \"Selektieren mit Bedingung\" oder \"Zählen von Elementen\" nutzen und diese dann in der jeweiligen Funktion, die halt als extra Datei vorliegt, weiter präzisieren. Sind erstmal nur Gedankenspiele von mir. Um die Brücke zwischen den 2 Systemen (MySQL und DB2) schlagen zu können, kann man ja Parameter als Arrays oder normale Variablen übergeben, die dann nur noch umgesetzt werden; also keinen direkten SQL.
 
Nächtliche Grüße

[Powie]

so wie es aussieht krieg ich das für DB2 nicht so hin wie ich mir das gedacht habe. Problematik ist die Partitionierung der Daten um sowas wie den Limit Befehl von Mysql nachzuahmen  :ugly: . Ich hab zwar noch nicht aufgegeben, aber so wie es aussieht ist es vermutlich nicht so machbar wie ich mir das gedacht habe....

[k00ni]

Könnten wir uns mal etwas PHP und SQL ansehen?

[Powie]

nein.. IBM Confidential   /uploads/emoticons/icon_e_surprised.gif.a8707b3f35a569cb4cfe563fc72ef78d.gif\" alt=\":-o\" />