In meinem Projekt möchte ich eine View haben, die dazu dient den Enviroment Variable für Email zu setzen. Wie kann ich die Environment Variablen ändern?
Ankündigung
Einklappen
Keine Ankündigung bisher.
Environment ändern
Einklappen
Neue Werbung 2019
Einklappen
X
-
Zitat von JaMa Beitrag anzeigenWarum möchtest du über deine Anwendung dessen Environment Variablen ändern?
Theoretisch musst du dafür einfach nur die entsprechende Environment File bearbeiten.
Kommentar
-
Kannst dir ja anschauen wie Laravel das bei "php artisan key:generate" selber macht: https://github.com/laravel/framework...ateCommand.php
Kommentar
-
Zitat von Tropi Beitrag anzeigenKannst dir ja anschauen wie Laravel das bei "php artisan key:generate" selber macht: https://github.com/laravel/framework...ateCommand.php
Kommentar
-
Hallo,
also wie das in Laravel ist, weiß ich nicht genau. Aber Du kannst doch in Symfony in den YAML Configs eigene Credentials, Datenbankverbindungen usw. pro Environment angeben. Wenn ich Dich richtig verstehe, dann ist doch das, das was Du willst? Oder nicht?
Mehr dazu findest Du in den Docs: https://symfony.com/doc/current/conf...ironments.html
Und im Normalfall kannst Du auch Configs für ein bestimmtes Environment auslesen in Deiner Laravel App. Die Möglichkeit müsst es definitiv geben.
Beantwortet das Deine Frage?
MFG
derwunner
Kommentar
-
JaMa Nicht so eindeutig. Jedenfalls, so wie ich die bisherigen Posts interpretiere. Außerdem, wenn man bei Laravel, Symfony & Co. etwas im Code nachschauen muss, dann macht man etwas falsch. Gerade bei den großen Frameworks ist doch alles sauber und auch mehrfach in verschiedener Form dokumentiert. Sogar mit Beispielen etc..
Kommentar
-
Ich schaue mir oft Code in Frameworks an um zu schauen, wie das andere gelöst haben, bzw. wie man etwas gut lösen kann (nicht immer, aber oft).
Das was der TE erstellt ist aber nichts was man bei normalen Laravel oder Symfony Projekten benötigt. Die E-Mail Settings in den Environment Variablen direkt über die Anwendung zu ändern macht eigentlich auch wenig Sinn."Software is like Sex, it's best if it's free." - Linus Torvalds
Kommentar
-
Zitat von derwunner Beitrag anzeigenJaMa Nicht so eindeutig. Jedenfalls, so wie ich die bisherigen Posts interpretiere. Außerdem, wenn man bei Laravel, Symfony & Co. etwas im Code nachschauen muss, dann macht man etwas falsch. Gerade bei den großen Frameworks ist doch alles sauber und auch mehrfach in verschiedener Form dokumentiert. Sogar mit Beispielen etc..
2. Grundsätzlich gebe ich dir bei sowas sogar Recht, im Framework-Code nachschauen zu müssen deutet darauf hin das entweder die Dokumentation schlecht ist oder man etwas sehr unkonventionelles machen will, was vermutlich keine gute Idee ist. Der verlinkte Code ist aber "Last Mile"-Code, d.h. er hat keine großartigen Abhängigkeiten zu dem Framework, sondern zeigt eigentlich (fast) nur das, was der TE auch machen will. Aber auch ansonsten ist es oft wesentlich einfacher den Code zu verstehen als Dokumentation.
- 1 Likes
Kommentar
-
LaraCasts sind Tutorials, was in erster Linie nichts mit der Dokumentation zu tun.
Das hier ist die offizielle Dokumentation zu Laravel, was kein Vergleich z.B. zu Symfony ist.
Trotz dem, dass die Komponenten von Symfony bei Laravel zum Einsatz kommen, sollte dokumentiert sein, wann und wie welche Komponenten zum Einsatz kommen."Software is like Sex, it's best if it's free." - Linus Torvalds
Kommentar
-
JaMa Ja ok, hast recht, es steht wirklich nirgendswo in der Laravel Doku, ob und wann sie Symfony Komponenten benutzen. Anscheinend wird Laravel immer mehr eigentständig. Das mit der Super Global $_ENV gibts ja in Symfony gar nicht. Das Environment gibt man einmal den HttpKernel mit. Und mittels des Container Patterns kann man es sich dann jederzeit in der App wieder holen. Das mit der Super Global Lösung von Laravel ist wirklich sowas von letztes Jahrhundert... Also ich weiß nicht, was sie sich dabei gedacht haben.
Auch habe ich gesehen, dass sie eine eigene Template Engine, sowie ORM und DBAL haben. Die Energie hätten sie besser mal in Doctrine bzw. Twig gesteckt, anstatt ihr eigenes Süppchen zu kochen. Doctrine bzw. Twig wird denen immer mindestens einen Schritt voraus sein. Deswegen ist damit konkurrieren eigentlich vergebene Lebensmühe. Das musste ich auch schon lernen, als ich hier nach Projekthilfe für mein Framework angefragt habe. Dementsprechend werde ich demnächst auf die beiden genannten Komponenten umstellen / umsteigen.
Kommentar
-
Laravel ist eigenständig, es nutzt nur einige Symfony Komponenten. Daran wird sich auch nichts ändern, da Laravel keinen Vorteil davon hätte die Komponenten selbst zu implementieren.
Der Grund warum Laravel Blade und Eloquent und nicht Twig bzw. Doctrine nutzt liegt einfach darin begründet, dass Laravel versucht den Entwicklungsprozess so einfach wie möglich zu halten versucht. Da passen Twig und Doctrine einfach nicht wirklich dazu.
Es geht dabei auch nicht darum wer wem einen Schritt voraus ist, sondern einfach um die Anwendung der Konzepte des Frameworks.
Auch konkurrieren die Frameworks nicht wirklich, da wie gesagt andere Ansätze und daraus resultierend auch etwas andere Anwendungsbereiche."Software is like Sex, it's best if it's free." - Linus Torvalds
Kommentar
Kommentar