Hi Vitalij, interessante Videos hast du da ! Auch dieses ist sehr lehrreich, mach bitte weiter so , in Bezug auf das Kritik Video. Heute hätte ich eine kleine Frage: wie heißt dein phpstorm plugin, mit dem die Tabs/inherits farblich eingefärbt werden? Schon mal danke
Vielen dank für dein Kommentar. Das Plugin was ich da nutze heißt Raindob Brackets, es färbt nicht nur die Tabs ein sondern auch alle Klammern(normal, geschweift, eckig) damit man auch sich in einem Array/JSON Objekt zu Recht finden kann. Hier kannst du dir das Plugin downloaden plugins.jetbrains.com/plugin/10080-rainbow-brackets
Hi Vitalij! Ich habe da etwas Bedenken bzw. Fragen zu dem UserRepository interface. Das Problem bei diesem Ansatz ist, dass das Repository immer größer wird mit der Zeit und du sehr schnell eine Gott-Klasse mit zu vielen Zuständigkeiten hast, Stichwort SRP (SOLID). Außerdem finde ich die Usability bzw. die Kombination von add und persist relativ unklar wo da der Zusammenhang ist. Mann müsste andere Entwickler schulen, dass man diese beiden Methoden immer in Kombination miteinander verwenden muss. Da fällt mir auf, dass sich nicht mehrere User gleichzeitig (pro Request) registrieren. Man könnte es also vereinfachen, mit einer einzigen Repository methode z.B. saveUser(UserEntity $userEntity). Gruss
Hey Daniel danke für das Feedback. Also das UserRepository folgt den Solid prinzipien, die Datenbank ist die einzige Zuständigkeit. Es kommen zwar immer mehr methoden dazu aber aus der Praxis her sind es meistens nicht so viele. Die Kombination aus add und persist habe ich im ersten Video erklärt. Wenn du das Repository in einem User Import benutzen würdest und sagen wir von einer API ein Batch an Usern importieren müsstest, dann kannst du nicht mit saveUser jedes mal an die DB gehen. Performance ist dabei schlecht. Add fügt die User erstmal in den Speicher und persist kümmert sich dann direkt um das Abspeichern. So hast du am ende nur ein SQL Query. Das selbe wird auch bei Doctrine angewandt. Um mehrere User pro Request speichern zu können, müsste man sich für diesen UseCase dann eine neue Action anlegen. Bei dem Standard fall wurde das nicht berücksichtig.
Wieder ein sehr schönes Video, an das Tempo muss man sich gewöhnen um dir folgen zu können. Warum machst du die Prüfung ob es den Benutzer gibt nicht in der validate? Dann hätte man nur noch eine Stelle für die Komplette Validierung, aktuell ist die Methode darauf angewiesen das extern nach dem User geprüft wird, weil wer das nicht macht, kann ein falsches Ergebnis erhalten
Validator ist dazu da um zu Validieren, nur das Repository soll die Quelle kennen. Stell dir vor ich würde die User nicht mehr in der DB speichern sondern nur noch via API Call auslesen und hätte eine APIUserRepository erstellt. Dann müsste ich den Validator mit anpassen. Das Single Responsibility Principle besagt dass eine Klasse eine Zuständigkeit hat. Validator ist zuständig um Varaiblen zu prüfen und Errors zu generieren, das Repository ist für die Datenquelle zuständig.
@@VitalijMik Wenn der Validator das Respository aufruft kennt er die Datenquelle doch auch nicht? Ansonsten würde ich den Fehler das es den User gar nicht gibt, nicht mit in den Valitator nehmen, weil diese Meldung an der Stelle aktuell nicht richtig sein könnte.
ja aber dann wäre der validator abhängig vom User Repository. ich würde gerne die abhängigkeit vermeiden. der validator wird eh nur in der action verwendet und wir teilen ihm sozusagen die informationen mit, die ihm noch fehlen. und wieso wäre die Meldung an der Stelle nicht richtig?
@@VitalijMik Du hast einen Standardwert false, wenn du diesen von außen nicht änderst, hat also der Validator keinen Einfluss drauf, gibst du zurück das es den User nicht gibt. Ob das von außen jemand kontrolliert hat, weiß du aber nicht
Das ist auch so gewollt. Der Validator hat die Aufgabe die Eigenschaften oder die Daten aus dem Request zu prüfen mehr nicht. Wenn es von Außen nicht gesetzt ist dann ist es auch so. Der Validator soll nicht seine Außenwelt kennen. Wenn dem Validator neimand mitteilt dass der User Doch exestiert, ist die Außenwelt schuld. Sprich der Fehler ist in der Action.
Sooo, Gestern hab ich auch dieses Video angesehen und mit durchgearbeitet. Ich bekomme aber leider immer eine Fehlermeldung, wenn der User zwar existiert, aber das Passwort falsch ist : -----------------CODE------------- Deprecated: Creation of dynamic property PhpFidder\Core\Components\Auth\Validator\LoginValidator::$errors is deprecated in /var/www/html/src/Components/Auth/Validator/LoginValidator.php on line 16 Fatal error: Uncaught Laminas\HttpHandlerRunner\Exception\EmitterException: Output has been emitted previously; cannot emit response in ... -----------------/CODE------------- Ich habe so eine Vermutung woran das liegt, aber ich bin NOCH nicht soooo konform mit dem Thema (Hab mit 46 Jahren zum Fachinformatiker umgeschult :D ) Nachdem ich mit meinem Code nicht weitergekommen bin, habe ich deinen Code heruntergeladen und kopiert, aber der Fehler bleibt. Meine Erklärversuche scheitern hier, aber es scheint, dass bei einem aktiven "$errors" - Array ein zweiter Versuch unternommen wird, den Emitter zu benutzen, welcher aber nur einmal verwendet werden darf... Somit komme ich nicht weiter :(
du hast vermutlich im abstract validator die errors auf private gestellt github.com/PHP-Fidder/Code/blob/main/src/Components/Core/AbstractValidator.php#L9 die müssen protected sein damit die vererbt werden. ohne protected, gibt es in der LoginValidator keine $errors properties und du würdest quasi dynamisch über $this-> die errors hinzufügen. das ist aber in den neuen PHP Versionen nicht mehr möglich. Der Fatal error ist einfach nur folgefehler. weil die erste meldung ausgegeben wurde, wurde somit bereits was "emitted"
@@VitalijMik Aaaah, aber auf private hab ICH die nicht gestellt, ich hab in deinem Repo eben nachgesehen, bei DIR steht das auch auf PRIVATE... ;) Anscheinend hast du immer nur die korrekten Daten eingegeben, so dass der Fehler dann bei Dir nicht aufgetaucht ist :D :D :D Egal, ich freue mich, weitermachen zu können, denn DIESER Fehler ist behoben ^^ Grüße Kigh
Änderungsvorschläge gerne in die Kommentare!! :D
Cool wie das Projekt heranwächst!
will ja auch voran kommen und das abschließen
Würde mich freue wenn das Thema Events in einem der nächsten Videos näher beleuchtet werden könnte. 👍
Gerne doch
Hi Vitalij, interessante Videos hast du da ! Auch dieses ist sehr lehrreich, mach bitte weiter so , in Bezug auf das Kritik Video.
Heute hätte ich eine kleine Frage: wie heißt dein phpstorm plugin, mit dem die Tabs/inherits farblich eingefärbt werden? Schon mal danke
Vielen dank für dein Kommentar.
Das Plugin was ich da nutze heißt Raindob Brackets, es färbt nicht nur die Tabs ein sondern auch alle Klammern(normal, geschweift, eckig) damit man auch sich in einem Array/JSON Objekt zu Recht finden kann.
Hier kannst du dir das Plugin downloaden
plugins.jetbrains.com/plugin/10080-rainbow-brackets
Hi Vitalij! Ich habe da etwas Bedenken bzw. Fragen zu dem UserRepository interface. Das Problem bei diesem Ansatz ist, dass das Repository immer größer wird mit der Zeit und du sehr schnell eine Gott-Klasse mit zu vielen Zuständigkeiten hast, Stichwort SRP (SOLID). Außerdem finde ich die Usability bzw. die Kombination von add und persist relativ unklar wo da der Zusammenhang ist. Mann müsste andere Entwickler schulen, dass man diese beiden Methoden immer in Kombination miteinander verwenden muss. Da fällt mir auf, dass sich nicht mehrere User gleichzeitig (pro Request) registrieren. Man könnte es also vereinfachen, mit einer einzigen Repository methode z.B. saveUser(UserEntity $userEntity). Gruss
Hey Daniel danke für das Feedback.
Also das UserRepository folgt den Solid prinzipien, die Datenbank ist die einzige Zuständigkeit. Es kommen zwar immer mehr methoden dazu aber aus der Praxis her sind es meistens nicht so viele.
Die Kombination aus add und persist habe ich im ersten Video erklärt. Wenn du das Repository in einem User Import benutzen würdest und sagen wir von einer API ein Batch an Usern importieren müsstest, dann kannst du nicht mit saveUser jedes mal an die DB gehen. Performance ist dabei schlecht.
Add fügt die User erstmal in den Speicher und persist kümmert sich dann direkt um das Abspeichern. So hast du am ende nur ein SQL Query. Das selbe wird auch bei Doctrine angewandt.
Um mehrere User pro Request speichern zu können, müsste man sich für diesen UseCase dann eine neue Action anlegen. Bei dem Standard fall wurde das nicht berücksichtig.
Wieder ein sehr schönes Video, an das Tempo muss man sich gewöhnen um dir folgen zu können. Warum machst du die Prüfung ob es den Benutzer gibt nicht in der validate? Dann hätte man nur noch eine Stelle für die Komplette Validierung, aktuell ist die Methode darauf angewiesen das extern nach dem User geprüft wird, weil wer das nicht macht, kann ein falsches Ergebnis erhalten
Validator ist dazu da um zu Validieren, nur das Repository soll die Quelle kennen.
Stell dir vor ich würde die User nicht mehr in der DB speichern sondern nur noch via API Call auslesen und hätte eine APIUserRepository erstellt. Dann müsste ich den Validator mit anpassen.
Das Single Responsibility Principle besagt dass eine Klasse eine Zuständigkeit hat. Validator ist zuständig um Varaiblen zu prüfen und Errors zu generieren, das Repository ist für die Datenquelle zuständig.
@@VitalijMik Wenn der Validator das Respository aufruft kennt er die Datenquelle doch auch nicht? Ansonsten würde ich den Fehler das es den User gar nicht gibt, nicht mit in den Valitator nehmen, weil diese Meldung an der Stelle aktuell nicht richtig sein könnte.
ja aber dann wäre der validator abhängig vom User Repository. ich würde gerne die abhängigkeit vermeiden. der validator wird eh nur in der action verwendet und wir teilen ihm sozusagen die informationen mit, die ihm noch fehlen.
und wieso wäre die Meldung an der Stelle nicht richtig?
@@VitalijMik Du hast einen Standardwert false, wenn du diesen von außen nicht änderst, hat also der Validator keinen Einfluss drauf, gibst du zurück das es den User nicht gibt. Ob das von außen jemand kontrolliert hat, weiß du aber nicht
Das ist auch so gewollt. Der Validator hat die Aufgabe die Eigenschaften oder die Daten aus dem Request zu prüfen mehr nicht. Wenn es von Außen nicht gesetzt ist dann ist es auch so. Der Validator soll nicht seine Außenwelt kennen. Wenn dem Validator neimand mitteilt dass der User Doch exestiert, ist die Außenwelt schuld. Sprich der Fehler ist in der Action.
Sooo, Gestern hab ich auch dieses Video angesehen und mit durchgearbeitet. Ich bekomme aber leider immer eine Fehlermeldung, wenn der User zwar existiert, aber das Passwort falsch ist :
-----------------CODE-------------
Deprecated: Creation of dynamic property PhpFidder\Core\Components\Auth\Validator\LoginValidator::$errors is deprecated in /var/www/html/src/Components/Auth/Validator/LoginValidator.php on line 16
Fatal error: Uncaught Laminas\HttpHandlerRunner\Exception\EmitterException: Output has been emitted previously; cannot emit response in ...
-----------------/CODE-------------
Ich habe so eine Vermutung woran das liegt, aber ich bin NOCH nicht soooo konform mit dem Thema (Hab mit 46 Jahren zum Fachinformatiker umgeschult :D )
Nachdem ich mit meinem Code nicht weitergekommen bin, habe ich deinen Code heruntergeladen und kopiert, aber der Fehler bleibt.
Meine Erklärversuche scheitern hier, aber es scheint, dass bei einem aktiven "$errors" - Array ein zweiter Versuch unternommen wird, den Emitter zu benutzen, welcher aber nur einmal verwendet werden darf...
Somit komme ich nicht weiter :(
du hast vermutlich im abstract validator die errors auf private gestellt
github.com/PHP-Fidder/Code/blob/main/src/Components/Core/AbstractValidator.php#L9
die müssen protected sein damit die vererbt werden. ohne protected, gibt es in der LoginValidator keine $errors properties und du würdest quasi dynamisch über $this-> die errors hinzufügen. das ist aber in den neuen PHP Versionen nicht mehr möglich.
Der Fatal error ist einfach nur folgefehler. weil die erste meldung ausgegeben wurde, wurde somit bereits was "emitted"
@@VitalijMik Aaaah, aber auf private hab ICH die nicht gestellt, ich hab in deinem Repo eben nachgesehen, bei DIR steht das auch auf PRIVATE... ;)
Anscheinend hast du immer nur die korrekten Daten eingegeben, so dass der Fehler dann bei Dir nicht aufgetaucht ist :D :D :D
Egal, ich freue mich, weitermachen zu können, denn DIESER Fehler ist behoben ^^
Grüße
Kigh
ja kann sein dass mir zu der Aufnahme der fehler nicht aufgefallen ist und ich habe es später dann behoben