moin, > > Kontextwechsel > > noch nie gehört? klar und angewendet. Du verwirrst mich. Den Cartoon der Seite den du als Link verwiesen hast, checke ich nich. > Bei Spaltennamen muss man auch aufpassen, `Rolf B` ist ein völlig korrekter Spaltenname. Aber er grillst Dir dein SQL, wenn Du ihn nicht in Backticks einschließt (MYSQL). Ich verwende immer Backticks. > > new InitDBContextPOPO > > Das ist kein POPO. Plain Old * Objects gehören thematisch zum fachlichen Modell. POPO Klassen haben doch außer dem `__construct()` keine Methoden und sind `readOnly` zugänglich. So habe ich es verstanden und das ist hier gegeben > Dein Objekt würde, glaube ich, lieber QueryContext heißen. Wenn dann `SQLContext` da ich die Initialisierung mit allen DQL, DML, DDL, DCL mache. > Dein Tables-Array ist - scheint mir - falschrum gebaut. Die Aliasnamen müssen üblicherweise eindeutig sein in einer Query, Tablenamen nicht. Wenn Du einen self join machen musst, geht das bei Dir schief. Es sollte 'tA' => 'tableA' heißen. nur n Beispiel. Mein Validator erkennt das. > > ->generalCondition(..., LogicConstant::_NONE) > > Warum eigentlich _NONE und nicht NONE? AND und OR sind Keywords und kann ich nicht nehmen also _AND und _OR. NONE hingegen nicht. Aber es sind nicht ordenlich aus wenn ich bei NONE kein unterstrich mache. > […] hier würde ein Defaultparameter helfen is auch drin > Was auch helfen kann, ist ein Set von Helper-Funktionen, die das Erzeugen von Interfaces und Containern kapseln. Ok hast du ne Lektüre parat? > Dann verschwindet eine Menge Technomantie aus einem Query-Build. Und durch schöne Variablennamen liest sich der Build der Query gleich wie ein Buch. Ich verschaffe euch mal ein UML Diagramm meines Projektes. Habe ich sowieso vor. > Man nennt sowas ein Fluid Interface - es sieht aus wie flüssige Sprache. Ok Lektüre? > Die Container sollten übrigens rein binär sein. Ein OR aus mit N Operanden lässt sich immer auf (N-1) ORs mit 2 Operanden zurückführen, und das macht die Programmierung vieeeel einfacher. War auch nur Beispiel. Ich habs hardgecoded um zu zeigen was die BETWEEN Klasse tun soll. > Warum heißen die Methoden des Querybuilders eigenlich generalXXXX? […] Warum da neue Namen erfinden? Aggregatoren muss GroupBy haben sonst beißen die sich. daher habe ich das getrennt von `->select()` in `generalSelect()` für CASE usw. und `->groupSelect()` für Aggregatoren wie `MAX()`. > Das $builder Objekt sollte übrigens nur die Methoden select, insert, update, delete und union kennen. bin noch an Coden > Vielleicht kann $builder auch Helper enthalten, die ColumnInterfaces oder LiteralInterfaces erzeugen.Und diese Interfaces können ihrerseits Builder-Helper enthalten: Wie sähe das wirklich konkret aus??? Hast du n SQL Builder zum Donload oder ist es SecretCode? Dann habe ich nicht gefragt 😉. > Das liest sich jedenfalls besser als deine Comparison Konstruktion. ok > Wichtig ist da auch eine API Konsistenz. Lektüre und Referenzen hast du? > Es ist merkwürdig, wenn ein LogicContainer die LogicConstant am Ende hat und eine Comparison die „EquotiationConstant“ (das Wort gibt's nicht) vorn. Diese Constant möchte vermutlich lieber ComparisonOperator heißen… Konkretes Beispiel: ~~~php class EquotationConstant { const EQUAL = '=', NOT_EQUAL = '<>' GREATER_THAN = '>' LESSER_THAN = '<'; } ~~~ desweiteren noch ArithmeticConstant +-*/ usw. > > was meinst Du mit manuelle Formatierung > > Ich meinte die von Dir überall verstreuten Aufrufe von toString oder auch getResult. Sowas sollten die Builder-Komponenten bei Bedarf selbst tun. es gibt kein `__toString()` sonder allefals `$expression->getString()` für den SQL Schnipsel und `$expression->getValues()` für ersetzungen der `?` in der WHERE-Clausel. lgmb

moin, > > Kontextwechsel > > noch nie gehört? klar und angewendet. Du verwirrst mich. Den Cartoon der Seite den du als Link verwiesen hast, checke ich nich. > "sanitize your database inputs“ - das ist der Kontextwechsel. Kannst du mir n Beispiel geben??? Ich steh auf n schlauch > Bei Spaltennamen muss man auch aufpassen, `Rolf B` ist ein völlig korrekter Spaltenname. Aber er grillst Dir dein SQL, wenn Du ihn nicht in Backticks einschließt (MYSQL). Ich verwende immer Backticks. > > new InitDBContextPOPO > > Das ist kein POPO. Plain Old * Objects gehören thematisch zum fachlichen Modell. POPO Klassen haben doch außer dem `__construct()` keine Methoden und sind `readOnly` zugänglich. So habe ich es verstanden und das ist hier gegeben > Dein Objekt würde, glaube ich, lieber QueryContext heißen. Wenn dann `SQLContext` da ich die Initialisierung mit allen DQL, DML, DDL, DCL mache. > Dein Tables-Array ist - scheint mir - falschrum gebaut. Die Aliasnamen müssen üblicherweise eindeutig sein in einer Query, Tablenamen nicht. Wenn Du einen self join machen musst, geht das bei Dir schief. Es sollte 'tA' => 'tableA' heißen. nur n Beispiel. Mein Validator erkennt das. > > ->generalCondition(..., LogicConstant::_NONE) > > Warum eigentlich _NONE und nicht NONE? AND und OR sind Keywords und kann ich nicht nehmen also _AND und _OR. NONE hingegen nicht. Aber es sind nicht ordenlich aus wenn ich bei NONE kein unterstrich mache. > […] hier würde ein Defaultparameter helfen is auch drin > Was auch helfen kann, ist ein Set von Helper-Funktionen, die das Erzeugen von Interfaces und Containern kapseln. Ok hast du ne Lektüre parat? > Dann verschwindet eine Menge Technomantie aus einem Query-Build. Und durch schöne Variablennamen liest sich der Build der Query gleich wie ein Buch. Ich verschaffe euch mal ein UML Diagramm meines Projektes. Habe ich sowieso vor. > Man nennt sowas ein Fluid Interface - es sieht aus wie flüssige Sprache. Ok Lektüre? > Die Container sollten übrigens rein binär sein. Ein OR aus mit N Operanden lässt sich immer auf (N-1) ORs mit 2 Operanden zurückführen, und das macht die Programmierung vieeeel einfacher. War auch nur Beispiel. Ich habs hardgecoded um zu zeigen was die BETWEEN Klasse tun soll. > Warum heißen die Methoden des Querybuilders eigenlich generalXXXX? […] Warum da neue Namen erfinden? Aggregatoren muss GroupBy haben sonst beißen die sich. daher habe ich das getrennt von `->select()` in `generalSelect()` für CASE usw. und `->groupSelect()` für Aggregatoren wie `MAX()`. > Das $builder Objekt sollte übrigens nur die Methoden select, insert, update, delete und union kennen. bin noch an Coden > Vielleicht kann $builder auch Helper enthalten, die ColumnInterfaces oder LiteralInterfaces erzeugen.Und diese Interfaces können ihrerseits Builder-Helper enthalten: Wie sähe das wirklich konkret aus??? Hast du n SQL Builder zum Donload oder ist es SecretCode? Dann habe ich nicht gefragt 😉. > Das liest sich jedenfalls besser als deine Comparison Konstruktion. ok > Wichtig ist da auch eine API Konsistenz. Lektüre und Referenzen hast du? > Es ist merkwürdig, wenn ein LogicContainer die LogicConstant am Ende hat und eine Comparison die „EquotiationConstant“ (das Wort gibt's nicht) vorn. Diese Constant möchte vermutlich lieber ComparisonOperator heißen… Konkretes Beispiel: ~~~php class EquotationConstant { const EQUAL = '=', NOT_EQUAL = '<>' GREATER_THAN = '>' LESSER_THAN = '<'; } ~~~ desweiteren noch ArithmeticConstant +-*/ usw. > > was meinst Du mit manuelle Formatierung > > Ich meinte die von Dir überall verstreuten Aufrufe von toString oder auch getResult. Sowas sollten die Builder-Komponenten bei Bedarf selbst tun. es gibt kein `__toString()` sonder allefals `$expression->getString()` für den SQL Schnipsel und `$expression->getValues()` für ersetzungen der `?` in der WHERE-Clausel. lgmb

moin, > > Kontextwechsel > > noch nie gehört? klar und angewendet. Du verwirrst mich. Den Cartoon der Seiten ckecke ich nich. > "sanitize your database inputs“ - das ist der Kontextwechsel. kannst du mir n beispiel geben??? Ich steh auf n schlauch > Bei Spaltennamen muss man auch aufpassen, `Rolf B` ist ein völlig korrekter Spaltenname. Aber er grillst Dir dein SQL, wenn Du ihn nicht in Backticks einschließt (MYSQL). Ich verwende immer Backticks. > > new InitDBContextPOPO > > Das ist kein POPO. Plain Old * Objects gehören thematisch zum fachlichen Modell. POPO Klassen haben doch außer dem `__construct()` keine Methoden und sind `readOnly` zugänglich. So habe ich es verstanden und das ist hier gegeben > Dein Objekt würde, glaube ich, lieber QueryContext heißen. Wenn dann `SQLContext` da ich die Initialisierung mit allen DQL, DML, DDL, DCL mache. > Dein Tables-Array ist - scheint mir - falschrum gebaut. Die Aliasnamen müssen üblicherweise eindeutig sein in einer Query, Tablenamen nicht. Wenn Du einen self join machen musst, geht das bei Dir schief. Es sollte 'tA' => 'tableA' heißen. nur n Beispiel. Mein Validator erkennt das. > > ->generalCondition(..., LogicConstant::_NONE) > > Warum eigentlich _NONE und nicht NONE? AND und OR sind Keywords und kann ich nicht nehmen also _AND und _OR. NONE hingegen nicht. Aber es sind nicht ordenlich aus wenn ich bei NONE kein unterstrick mache. > […] hier würde ein Defaultparameter helfen is auch drin > Was auch helfen kann, ist ein Set von Helper-Funktionen, die das Erzeugen von Interfaces und Containern kapseln. Ok Lektüre parat? > Dann verschwindet eine Menge Technomantie aus einem Query-Build. Und durch schöne Variablennamen liest sich der Build der Query gleich wie ein Buch. Ich verschaffe euch mal ein UML Diagramm meines Projektes. Habe ich sowieso vor. > Man nennt sowas ein Fluid Interface - es sieht aus wie flüssige Sprache. Ok Lektüre? Die Container sollten übrigens rein binär sein. Ein OR aus mit N Operanden lässt sich immer auf (N-1) ORs mit 2 Operanden zurückführen, und das macht die Programmierung vieeeel einfacher. > War auch nur beispiel. Ich habs hardgecoded um zu Zeigen was die BETWEEN Klasse tun soll > Warum heißen die Methoden des Querybuilders eigenlich generalXXXX? […] Warum da neue Namen erfinden? Aggregatoren muss GroupBy haben sonst beisen die sich. daher habe ich das getrennt von `->select()` in `generalSelect() für CASE usw. und `->groupSelect()` für Aggregatoren wie `MAX()`. > Das $builder Objekt sollte übrigens nur die Methoden select, insert, update, delete und union kennen. bin noch an Coden > Vielleicht kann $builder auch Helper enthalten, die ColumnInterfaces oder LiteralInterfaces erzeugen.Und diese Interfaces können ihrerseits Builder-Helper enthalten: Wie sähe das wirklich konkret aus??? Hast du SQL Builder zum Donloaded oder ist es Secret Code? Dann habe ich nicht gefragt 😉 > Das liest sich jedenfalls besser als deine Comparison Konstruktion. ok > Wichtig ist da auch eine API Konsistenz. Lektüre und Referenzen hast du? > Es ist merkwürdig, wenn ein LogicContainer die LogicConstant am Ende hat und eine Comparison die „EquotiationConstant“ (das Wort gibt's nicht) vorn. Diese Constant möchte vermutlich lieber ComparisonOperator heißen… Konkretes Beispiel: ~~~php class EquotationConstant { const EQUAL = '=', NOT_EQUAL = '<>' GREATER_THAN = '>' LESSER_THAN = '<'; } ~~~ desweiteren noch ArithmeticConstant +-*/ usw. > > was meinst Du mit manuelle Formatierung > > Ich meinte die von Dir überall verstreuten Aufrufe von toString oder auch getResult. Sowas sollten die Builder-Komponenten bei Bedarf selbst tun. es gibt kein `__toString()` sonder allefals `$expression->getString()` für den SQL Schnipsel und `$expression->getValues()` für ersetzungen der `?` in der WHERE-Clausel. lgmb