funktionalität in Konstruktoren ähnlicher Klassen besser machen???

[Rolf B]

Hallo MB,

so, hab zum Antworten ein neues Fenster aufgemacht, sonst wird das nix...

Kontextwechsel - nie gehört

Das erstaunt mich. Es ist im Forum ständiges Thema. Das Wiki hat einen Artikel. Der Comic bezieht sich auf einen Schüler mit dem Namen Robert'; DROP TABLE Students; --

Das ist eine typische SQL Injektion zum Sabotieren von Websites, die massive Security-Fehler aufweisen. Man muss drei Fehler machen: Erstens: Diesen Namen blindlings in ein SQL Statement einbauen, z.B. so:

$sql = "SELECT * FROM Students WHERE name='$_POST[name]'";

dann entsteht daraus

SELECT * FROM Students WHERE name='Robert'; DROP TABLE Students; --'

Zweitens: Das Ausführen mehrerer Statements in einem Execute gestatten und Drittens: Dem DB-Account der Website mit zu hohen Rechten ausstatten. Trifft all das zusammen, ist die Students Tabelle nach einer Query auf diesen Namen futsch. Deswegen "Exploits of a Mom" - die Mama hat den Namen ihres Sohnes genutzt, um der Schule zu beweisen wie mies ihre Seite gestrickt ist, und macht sich dann auch auch noch lustig darüber, als die Schule anruft und sich beschwert. Randall Monroe at his best :)

POPO

Du hast meinen Einwand einfach nicht beachtet. POxO Objekte sind eine Methode, wie man sein fachliches Modell aufbaut. Außerhalb des fachlichen Modells hat der Begriff nichts zu suchen. Zumindest habe ich das so verstanden. Es mag andere Sichten geben. Die Wikipedia schreibt zum POJO, dass der Begriff "hauptsächlich" im ORM-Bereich auftaucht. Das schließt weitere Nutzungen, wie bei Dir, nicht aus. Insofern: streiche diesen Einwand.

Key/Value Ordnung im Tables Array wird vom Validator sichergestellt

Was erkennt dein Validator?

SELECT *
FROM table A LEFT JOIN table B ON a.id = b.parent_id

Würde der Validator einen solchen Self-Join (den man zum Auflösen von Hierarchien braucht) zurückweisen?

AND und OR sind Keywords, das geht nicht

Doch, das geht. Du musst nur PHP 7 nehmen. In PHP 5.6 wird es abgewiesen, aber das solltest Du ohnehin nicht mehr verwenden.

Lektüre zu Helper-Funktionen / Fluid Interfaces

Nö, hab ich nicht. Sowas ist mir einfach schon in anderen APIs begegnet und ich fand es klasse. Das muss man für den jeweiligen Zweck ohnehin selbst konzipieren. Es ist dabei oft so, dass solche Methoden entweder $this zurückgeben (für Kettenaufrufe wie $this->addColumn("a")->addColumn("b")) oder neue Objekte erzeugen und zurückgeben (das war mein $this->between(...)->and($this->in(...)) Beispiel). Ein Methodenname and setzt natürlich auch PHP 7 voraus, offenbar haben die den 7er Parser aufgeschlaut.

Bei Helpern und Fluid gilt natürlich auf wieder: Nicht übertreiben.

generalSelect vs groupSelect

Ok, kann man machen. Aber es widerspricht der „don't make me think“ Idee und man muss die Methoden auch nicht zwingend trennen. Aggregatfunktionen oder HAVING ohne GROUP BY geht schief, ja, aber das fällt spätestens dem SQL Server auf. Da deine select-Funktion nicht in die Zukunft schauen kann, wäre es hilfreich, wenn Du deinen Generator in 2 Teile teilst: (1) Syntaxbaum aufbauen (also eine Objektstruktur, die das Statement repräsentiert und (2) SQL aus dem fertigen Baum generieren. Dann kann man vor der Generierung noch einen Plausi-Check einfügen. Man kann es aber auch lassen und die Fehlermeldung dem SQL Server überlassen. GIGO halt.

Wie sähe das wirklich konkret aus???

Tja - ich habe nichts als Vorlage. In dem Umfang habe ich noch nichts selbst gebaut. Was ich mal gemacht habe ist ein Logging-Helper mit Fluid-Interface, aber das ist betriebsintern und daher nicht veröffentlichbar. Was ich auch gemacht habe, ist ein Script-Interpreter für die Konfiguration unserer Callcenter-Software, da habe ich aber den Parser nicht selbst geschrieben sondern ANTLR verwendet. Der ANTLR Parser generiert aus dem Quelltext einen Syntaxbaum und verwendet dann das Besucherpattern, um den vom Parser erzeugten Syntaxbaum verarbeitbar zu machen - das war bisher mein intensivster Kontakt zu diesen Konzepten. Fluid Interfaces habe ich in der Patterns and Practices Library von Microsoft kennengelernt, die aber an vielen Stellen auch ein Musterbeispiel für Overengineering ist.

Ich wollte gestern Abend mal - interessehalber - eine Basis für einen eigenen SQL Generator erzeugen, bin aber nicht weit gekommen, mangels anderer dringender Dinge die zu tun waren.

Lektüre Lektüre Lektüre Referenzen Referenzen Referenzen

Warum bist Du da derart hinterher? Verlangst Du Belege für die Tauglichkeit meiner Aussagen? Oder suchst Du bloß weiterführende Informationen? Wenn's ersteres ist: KFO. Wenn's letzeres ist: Tja. Ich erzähle hier letztlich über meine Erfahrungen aus 35 Jahren Softwareentwicklung. Ich habe im Laufe der Jahre viele Bücher gelesen, wie Robert Martins Clean Code, die Patterns der Gang of Four, vor langer Zeit auch die damals existierenden Teile von Donald Knuths Art of Computer Programming (das Game Of Thrones der Informatik) oder Robert Sedgewicks Algorithms - und viel viel Code anderer Leute und Texte im Netz. Daraus habe ich viel mehr gelernt als aus Büchern; vor allem hier im Forum.

EquotationConstant

Was ich sagen wollte: Es gibt den Begriff der „Eqoutation“ nicht. Es gibt Equation (Gleichung / Gleichsetzung). Du meinst Comparison (Vergleich). Und deine EquoationConstant sollte um <= und >= ergänzt werden.

es gibt kein __toString()

Das schreibst Du nun schon zweimal. Was ich meinte, ist: Das KÖNNTE es aber geben. __toString ist eine magic method von PHP, die von PHP automatisch aufgerufen wird wenn ein Objekt wie ein String verwendet wird. Das Gegenteil von automatisch ist manuell - und das machst Du, wenn Du ->toString() immer dann aufrufst wenn Du es brauchst.

Rolf