Ankündigung

Einklappen
Keine Ankündigung bisher.

Objekt als Service/Parameter dynamisch aus einem Controller festlegen

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • [Symfony] Objekt als Service/Parameter dynamisch aus einem Controller festlegen

    Hey,

    bei einem etwas umfangreichen Projekt, dass wir aktuell auf Symfony übertragen, hatten alle Seiten zwei mögliche Pfadmuster: Entweder eine globale Variante (z.B. /angebote) oder eine lokale Variante, in der dann Inhalte entsprechend aus der Datenbank gefiltert wurden (/hamburg/angebote, es werden nur Angebote aus Hamburg angezeigt).

    Beide Pfade laufen aufs gleiche Twig-Template, bei der lokalen Seite wird die Datenbank-Anfrage entsprechend angepasst, dass nur relevante Inhalte angezeigt werden.

    Da kommen wir auch schon zum ersten Problem/Frage: Aktuell werden beide Routes jeweils bei der Action definiert, etwa so:
    PHP-Code:
    class Controller
    {
        
    /**
         * @Route("/", name="global")
         * @Route("/{portal}", name="local")
         */
        
    public function index(Portal $portal) { }    

    Aber bei 10-20 Controllern und mehr wird das halt irgendwann sehr mühselig. Und außerdem nicht sehr pflegbar. Vererbung scheint nicht zu klappen, da die Annotations von der Eltern-Klasse nicht übernommen werden. Und einen eigenen Loader zu implementieren schien mir irgendwie Over-Engineered. Ich hatte es auch schon mit Route-Gruppen versucht, aber bekam da keine sinnvolle Lösung zum laufen. Gibt es da von eurer Seite vielleicht Ideen, Ansätze?


    Des Weiteren, da besonders auf der Startseite sehr viele Inhalte aus verschiedenen Datenbank-Tabellen ausgelesen werden, sind die einzelnen Themenbereiche als eigene Twig-Funktionen definiert, gebündelt in einer Twig-Extension. Nun gibt es eine Funktion, die zwischen die Themenbereiche Werbung schalten soll. Damit in Hamburg auch für Hamburg relevante Werbung angezeigt wird muss das Portal mit übergeben werden.

    Man könnte es natürlich im Controller der render()-Funktion als Parameter mitgeben und dann an die Twig-Funktion weiterleiten, ich fragte mich nur, ob man das ganze auch eleganter als Service lösen kann, sprich, dass das Portal irgendwie dynamisch festgelegt wird und dann per Auto-Wiring vllt sogar injected werden kann, idk. Ich hab das Service-System von Symfony noch nicht genau genug durchblickt, um mir vorstellen zu können, wie das klappen könnte.

    Die Idee wäre, dass es eine Loader-Klasse gebe, die per __construct() dann das Portal-Entity injecten kann. Diese Loader-Klasse könnte dann beim Aufrufen der Twig-Funktion jeweils ausgeführt werden und den nächsten Banner ermitteln.

    Falls ihr Ideen oder Ansätze habt gerne her damit. Es reichen auch Stichpunkte oder Referenzen, die ich mir dann gerne anschaue. Denkanstöße sind aktuell genau das, was ich suche.


    Liebe Grüße und vielen Dank.


  • #2
    Symfony hat ja ein recht umfangreiches Event System. Ich könnte mir gut vorstellen, dass du dich hier auf das kernel.request Event einhängen kannst und dann ein Request Attribute mit deinen benötigten Informationen anlegen kannst.Dieses Request Attribute kannst du dann an verschiedenen Stellen wieder abfragen. Das _locale Attribute ist z.B. so ein Attribute.

    Thanks to the public attributes property, you can store additional data in the request, which is also an instance of Symfony\Component\HttpFoundation\ParameterBag. This is mostly used to attach information that belongs to the Request and that needs to be accessed from many different points in your application.
    The HttpFoundation Component (Symfony Docs)
    The HttpKernel Component (Symfony Docs)
    Built-in Symfony Events (Symfony Docs)

    Kommentar


    • #3
      Das klingt vielversprechend, danke. Schaue ich mir mal heute an und berichte, wie's geklappt hat

      Kommentar


      • #4
        Werbung.
        Klingt nach etwas, was potentiell besser via twig>{varnish>esi oder ajax}>{deno oder node} gelöst werden könnte.
        Aber gibt zig Möglichkeiten sowqs sauber zu lösen.
        Werbung ist nur halt so ein Aspekt, der gerne die Performance einer Seite negativ beeinflusst und genau das am wenigsten tun sollte. Man könnte die Anzeigen wahrscheinlich gut für einen gewissen Zeitraum im Arbeitsspeicher halten.
        Standards - Best Practices - AwesomePHP - Guideline für WebApps

        Kommentar

        Lädt...
        X