sessie en cookie
Ja maar zodra de argumenten niet vaststaan kunnen we ze niet meegeven aan de contructor, right? En om iets een service te laten zijn, hadden we besloten dat de argumenten altijd hetzelfde moeten zijn. Ik geef de global data dus niet mee aan de constructor, want die is niet altijd hetzelfde. Ik hou me dus nog steeds aan de norm van een service.... Jij daarentegen :) Jij gooit variabele data in de constructor, waardoor jouw request dus eigenlijk geen service meer is, en vervolgens voeg je het request object dan maar toe aan de services, terwijl het hele request-object nergens in je services-configuratie is terug te vinden. En dan is mijn oplossing niet mooi? ;-)))))
Nu ik er zo over nadenk valt er voor beide wel wat te zeggen. En dan heb ik precies mijn doel bereikt, er zit een gedachte achter de code. Maar of die gedachte goed is... :P
[semi-offtopic]
Ik heb me zelf ook nog nooit zoveel bemoeit met de request service in Symfony. Er zijn al heel wat discussies over geweest. En heel wat features, scopes, synchronized services, abstract services, zijn er in de DI component gekomen omdat Fabian (author van Symfony) het perse via de constructor wil doen en support wil bieden voor subrequests.
[/semi-offtopic]
Hehe, dat werd tijd ;-)))
Soms is het handiger om met je boerenverstnd iets op te lossen, dan om vast te houden aan iets zonder dat daar echt een goede reden voor is. In dit geval denk ik dat "mijn" manier wat efficiënter is, en dat de request ook echt een service is. Mijn motto is, als iets op een simpele manier kan, dan moet je het ook op een simpele manier doen (tenzij de meer ingewikkelde manier aanzienlijke voordelen biedt, maar dat is in deze situatie niet het geval).
Anyhow, we hebben weer even lekker gebrainstormd :)