<lsmith> aloha fabien
<lsmith> give me 5 mins .. finishing up a scrum meeting
--> gerryvdm_work (~gerryvdm@office.morris-chapman.be) has joined #symfony
--> jetienne (~jerome@ivr94-6-82-230-255-246.fbx.proxad.net) has joined #symfony
--> noginn (~noginn@86.12.191.129) has joined #symfony
<Seldaek> fabpot, lsmith, feel free to discuss that here :)
--> alecs (~alecs@82.208.174.229) has joined #symfony
--> jetienne_ (~jerome@ivr94-6-82-230-255-246.fbx.proxad.net) has joined #symfony
<-- alecs (~alecs@82.208.174.229) has left #symfony
<fabpot> Seldaek: we will
--> [OES] (~leesmith@client-86-23-54-218.brhm.adsl.virginmedia.com) has joined #symfony
<lsmith> ok ready fabpot
<fabpot> lsmith: I suppose you are not convinced with my last email, are you?
<lsmith> fabpot: well lets say i just want to go through it .. i am not convinced in either direction
<Seldaek> the main benefit I see, from what we did here, is that you can easily inject config variables in every controller, and they're all in one place (SC config)
<Seldaek> apart from that, I don't really care either way about injecting or pulling services, so I'll let you guys beat that horse :p
<lsmith> yeah .. my main point is .. the SC is able to handle injection
<fabpot> Seldaek: ok, perhaps we can fast forward the discussion easily if you read my last email about my last week experiments
<lsmith> and so why introduce a separate concept for injection into controllers
<fabpot> basically, my last experiments shows that we need the Container to be injected anyway in the controllers
<lsmith> but i do see your argument as well .. having the SC instance inside the controller makes a lot of situations easier
<fabpot> this is not a separate concept
<fabpot> a controller is a totally different beast
<fabpot> it's not a "global" object
<lsmith> well
<fabpot> it's more like a Model object, and models are not managed by the DI either
<lsmith> its still injection .. and in one place you inject via the SC .. and in the other with a naming convention
<epic_shadows> what are you guys working on ?
<lsmith> epic_shadows: symfony2
<epic_shadows> cool
<fabpot> well, then why not use the DI to manage your models?
<fabpot> or any other class for that matter
<Seldaek> lsmith: actually, what he proposed last is to just inject the SC, and no naming conventions at all
<lsmith> what about parameters?
<Seldaek> $sc['param'] $sc->service
<lsmith> let me check if i overlooked something
<Seldaek> but those are global sc params, not defined per controller
<lsmith> right .. what about sc specific parameters?
<Seldaek> which is what I prefer about the full DI for controllers, that you can easily have one parameter array for each controller
<fabpot> what do you mean by "specific"?
<lsmith> the maxPerPage thingi
<-- mgco3 has quit (Remote host closed the connection)
<fabpot> $container['maxPerPage']
<Seldaek> I guess you could do: parameters: controllerFoo: [], contorllerBar: [] etc
<lsmith> well what if you want different maxPerPage per controller?
<Seldaek> and then grab $sc['controllerFoo']
<victoria> hi, where can I find the description for all the options in generator.yml (sfDoctrineGenerator)?
<fabpot> you can define and manage the parameters the way you want
--> Kasu (~some@81-234-83-185-o1122.telia.com) has joined #symfony
<fabpot> $container['controllers.post.maxPerPage']
<lsmith> well .. some level of standardization here would be good to help people share code
<lsmith> we all know you can do anything you want with symfony2 :)
<fabpot> of course, that's really about documentation and convention
<fabpot> documentation will be very important with Symfony 2 to avoid people doing "stupid" things
<lsmith> so what are the drawbacks of using the SC for controller?
<lsmith> the main one was optional dependencies
<fabpot> you mean, the drawbacks of using SC to create controllers?
<lsmith> let me read your email again .. because i didnt really understand this "we must" pass the SC to th controller
<lsmith> fabpot: yes
<fabpot> lsmith: hehe, I don't even know where to start
--> andyman3000 (~Miranda@e177222203.adsl.alicedsl.de) has joined #symfony
<lsmith> the main issue i currently see is optional dependencies
<fabpot> I don't want to force people to create XML/YAML/... for every controller
<andyman3000> hi am am having issues with unit testing
<fabpot> and if we generate those automatically for them, then your point is moot
<andyman3000> i cannot load helpers in my unit tests. i alwys get ' The "default" context does not exist.'
<lsmith> fabpot: well in most cases you will need the same dependencies in most controllers
<Seldaek> fabpot: one thing though, I see yout point aobut making it easy and "hiding" the DIC from most coders, but is that really realistic? Don't you think you'll always end up in a situation when you'll need to define your own service and will have to learn about it?
<lsmith> and in the cases where you dont .. you can just manually change the generated defaults
<fabpot> lsmith: ok, but "most cases" means you cannot have one way to create controllers
<fabpot> Seldaek: that's also why I favor Approach 1 now
<andyman3000> is there a way to get around this somehow? i tried to change the bootstrapping but no luck
<lsmith> fabpot: the way i see it .. you generate a new controller .. with a default config in the SC . if you need to change the services injected by default .. you edit the SC config (and your controller class)
<fabpot> lsmith: but a service definition is only for one given class. It's not generic. So, I don't understand how you can have one default service definition
<lsmith> what i love about the sc is .. i have a single location where i can find all my deps
<lsmith> say i change a service ..
<lsmith> with everything in the SC .. i can just have a look there and know what will be affected
<Seldaek> fabpot: I think he means generate a default config into the sc when you create a new controller with the CLI tool
* lsmith nods to Seldaek
<fabpot> Seldaek: that's a nightmare. You will have tons of controller definitions in your XML configuration file, and in the cache
<lsmith> fabpot: we have them in a separate yaml file we import
<fabpot> ... and it is not needed as soon as you realize that most controllers need the Container anyway
<lsmith> but that means its impossible to know the dependencies of your controller
<lsmith> because they all can essentially depend on anything
<Seldaek> fabpot: myeah, we got a controller.yml with 20 controllers defined here, it's a bit long but not too bad with merge keys
<fabpot> the separate file changes nothing as everything is compiled down to one PHP class
<Seldaek> which is sitting in apc.. :)
<lsmith> fabpot: so you are worried about the performance?
<fabpot> 20 controllers is nothing is a real project
<Seldaek> hey it's a very real project:)
<fabpot> lsmith: not really about the performance, more about having a clean, simple approach
<fabpot> Seldaek: I don't say the contrary, just that when you will start to install bundles, they will come with their own controllers, and it will add up quickly
<lsmith> well i am not convinced how your approach is any more clean or simple
<fabpot> ok, how do you import the bundle controller configurations?
<fabpot> I mean, third party bundles
<lsmith> import :)
<fabpot> you have installed
<jamiel> andyman3000: You need to create a fake context to test if your class you are testing depends on helpers, ... just like your functional test does (see test/bootstrap/functional.php)
<lsmith> i like being able to disable things in the SC too
<lsmith> like i want to disable a controller
<lsmith> i can just do so in the SC
<fabpot> lsmith: you mean that the developer will need to import this by hand?
<lsmith> think of /. effects
<lsmith> fabpot: yes
<lsmith> no magic :)
<fabpot> lsmith: but not simple anymore
<fabpot> that's a lot of things you need to know
<lsmith> why is it not simple? i think we both agree that developers will need to know the SC config
<andyman3000> jamiel: thanks
<fabpot> ok, but they need to be able to start playing with Symfony 2 without too much knowledge
--> nresni (~nresni@actualys.pck.nerim.net) has joined #symfony
<fabpot> that's the problem with symfony 1, you need to learn a lot before you can start playing with it
<lsmith> a CLI command should get them up and running with a new controller quickly
<fabpot> if you have a look at the current tutorial for Symfony 2, you will see that you can do a lot of things without knowing anything about the DIC
<lsmith> if they need some additional services .. they have already stepped beyond the first "just playing"
<lsmith> also with the controllers being managed by the SC
<lsmith> you can work with bundles a lot better
<lsmith> i think i have mentioned this on the list already
<lsmith> say bundles depend on each other
<fabpot> not really, because the main services are hidden behind a getter like getUser, getRequest
--> freezed (~52f489ab@gateway/web/freenode/x-nlgirnghnitypyht) has joined #symfony
<freezed> Hello everybody
<lsmith> like one bundles controller actually calls another controller
<fabpot> that's already possible
<freezed> How can I add a signin form from sfDoctrineGuardPlugin in the frontend app ?
<lsmith> so in that case the controller would be in the SC?
<fabpot> nope
<fabpot> here is the forward implementation:
<fabpot> return $this->container->getControllerLoaderService()->run($controller, $parameters);
<lsmith> and what would $controller be?
<lsmith> the name?
<lsmith> and what if the controller that calls the other controller doesnt make the name configurable?
<lsmith> if things would be managed by the SC .. it would be automatic
<fabpot> yes: HelloBundle:Hello:fancy for instance
<lsmith> imho .. we have the SC for good reasons .. and they also apply for controllers :)
<fabpot> nope
<fabpot> because we need to manage inheritance
<fabpot> and that cannot be managed by the DIC
<lsmith> to me the SC is about dependencies .. and less about managing instances
<fabpot> When I say 'HelloBundle:Hello:fancy', it can be from Bundle\ or Application\
<lsmith> but if i havent convinced you at all yet .. then i think its ok .. its not a be all end all decision for me
<victoria> hi, sorry for repeating myself ...
<victoria> where can I find the description for all the options in generator.yml (sfDoctrineGenerator)?
<fabpot> lsmith: I will try to implement something like you describe to have a better feeling for it
<fabpot> lsmith: playing with things is always better than long discussions ;)
<lsmith> also i have a meeting in 15min where i am presenting
<lsmith> need to prepare :-/
* lsmith nods
<fabpot> lsmith: ok, ttyl