Framwork Vorschlag - Feedback erwünscht

    Quote from AndiPalm

    Ich habe jetzt mal in dein ( Lexan) Repository reingeschaut. Sehe aber bisher nur zahlreiche .md Files... ist das so gedacht oder mache ich was falsch?


    Was mir dabei aber aufgefallen ist: Du möchtest die prepared Statements mit der mysql.class.php umsetzen, richtig? Davon würde ich wirklich abraten. Es gibt bereits eine wesentlich modernere "Database" Klasse die man über den Container bekommen kann. Wird bisher nur wenig genutzt, kann aber viel mehr.

    Allerdings frage ich mich dann auch ob man nicht direkt auf Doctrine geht. Es muss ja nicht direkt der Schritt zum ORM sein, aber der Doctrine DBAL scheint mir eigentlich nur Vorteile zu haben. Bei solch zentralen Dingen bin ich immer eher ein Fan von Standards als von Eigenbräu.

    Was denkst du?

    naja ein paar änderungen diesbezüglich sind schon durch.
    sollten auch im Repo zu sehen sein.
    die .md files sind einfach nur für alle da, damit wenn jemand anders via ki mit dran arbeiten will, die selben standards bestehen.


    deswegen hatte ich ja den Vorschlag gepostet für den Ablauf ^^
    aber Doctrine DBAL könnte man in Phase 6 mit einpfflegen, jetzt lass ich erstmal step by step die SQL Injection abarbeiten

    Okay, die Commits waren scheinbar noch nicht nach Github gepusht. Jetzt sehe ich was.


    Und ich sehe, dass du schon fleißig was durch die KI jagst. Aber können wir das vielleicht nochmal besprechen bevor du jetzt alles umbaust? Ich habe da durchaus ein paar Kritikpunkte.


    Ich möchte jetzt nicht noch einen dritten selbst (oder von KI) geschriebenen DatabaseService haben. Entweder wir arbeiten vorläufig weiter mit mysql.class.php (würde ich eher von abraten) oder wir nutzen die schon vorhandene "Database"-Klasse oder wenn wir mit beiden unzufrieden sind, dann sollten wir direkt zu Doctrine gehen.

    Dann sollten wir meiner Meinung nach "named Parameters" benutzen. Die Queries werden sonst ja teilweise noch schlechter lesbar. Ich möchte in einer 10 Zeilen langen Query mit 4 JOINS nicht die "?" zählen müssen.

    ich bin da für alles offen, dafür bin ich nicht tief genug in der materie drinn um alles zu kennen.

    die Meinung der KI war

    "Die Roadmap sieht Symfony-Komponenten für später vor (Phase 6+). Zu dem Zeitpunkt kann Doctrine DBAL den DatabaseService unter der Haube ersetzen — die API bleibt gleich"

    insofern denke ich das lässt sich dann auch entsprechend umsetzten.
    Der einzige Kritikpunkt den ich gesehen habe waren neue dependencies, aber ich denke das können wir bei so einem umfang getrost in kauf nehmen

    Ist auch nicht als Vorwurf gemeint.


    Ich glaube nur, dass es vom Prozess her sinnvoller wäre erstmal einen kleinen Teil umzubauen, dann ein Feedback einzuholen und danach weiter zu machen. Ich bin beispielsweise mit einigen Änderungen der KI nicht einverstanden. Kann man vermutlich mit kleinen Anpassungen am Prompt beheben, aber dann muss man halt nochmal alles durchrattern lassen und vor allem muss man dann nochmal alles kontrollieren. Das ist eher suboptimal.


    Außerdem sollten wir vermutlich erstmal das PHP8.5 Thema fertigstellen bevor wir den nächsten PR mit 20.000 Zeilen Diff haben der dann lange auf einen Merge warten muss.


    Ich möchte deinen Enthusiasmus keinesfalls bremsen... nur ein kleines bisschen "lenken" ;)

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login