Parameters

Hi jverdeyen!

Wow! Congratulations - that's a pretty serious accomplishment :).

So, here's what I can say:

A) You should compile the container, and then actually require the cached container before anything else. The core Kernel class is a good guide: https://github.com/symfony/.... This means that you won't actually use the `$container` variable in your code as your container - that code will only run when there is *no* cached container. And then you will actually require the cached container.

B) Once you're using the cached container, you'll want to set the request_stack onto *that* container. I bet the problem is that you're setting the request_stack on your cached container, and then later on (in some code you don't have printed here), you're requiring the cached container. With that setup, the cached container indeed won't have the request_stack.

Let me know if that helps! I think you're one minor step away - it looks awesome!

Yes, it's working! Thanks! I didn't know I could set a service on a cached and compiled container. Thanks for the core Kernel example! I'm learning the Symfony internals by building it with the components, from scratch. Thanks Ryan

Sweet! Keep it up man :)

Okay so I went through the topic of dependency injection extensions of this video and that made a lot of sense and I was able to achieve what I wanted.

This is what my AppExtension class looks like

class AppExtension extends Extension
{

    public function load(array $configs, ContainerBuilder $container)
    {

        $loader = new Loader\xmlFileLoader($container, new FileLocator(__DIR__.'/../Resources/config'));
        $loader->load('services.xml');

        $configuration = new Configuration();
        $config = $this->processConfiguration($configuration, $configs);

        $container->setParameter('app.comments', $config['comments']);

    }

    public function getAlias(){
        return 'app';

    }
}

This is my configuration class and I understand now that this class is also important if one needs to set parameters, earlier I did not have this setup

class Configuration implements ConfigurationInterface
{

    public function getConfigTreeBuilder()
    {
        $treeBuilder = new TreeBuilder();
        $rootNode = $treeBuilder->root('app');
        $rootNode->children()->scalarNode('comments')->end();
        return $treeBuilder;
    }
}

Now I can send the value of comments from controller to twig.

I still do have some questions just so that my concept is clear.

1) Can we not set the value of parameter comments in extension or configuration class? Please note that comment is just a dummy name I am using as an example.

2) If the above is true then must we add the app.comment in config.yml? or it is important that we add it in config.yml as this is the only way for controller to access it and pass the value to twig?

3) Is there anyway to access comment value directly in twig rather than passing the value to twig via controller?

Hey Shairyar!

Ok, nice job with this! Creating extensions can be challenging, but you also don't need an extension class unless you're building a re-usable bundle. Otherwise - it's overkill: if you want to set a "app.comments" parameter, you could add a "parameters" key at the top of config.yml and set it there. The extension class is just if you need to have things like this easily configured by some external developer (because you've shared your bundle).

To answer your questions, let me explain how all of this works :).

A) Suppose you want to set a parameter called "app.comments" to 10 (this is basically what you're doing with your code). There are several ways to do this, the easiest is:

# config.yml
parameters:
    app.comments: 10

Yep, that's it :). So, why would you make it harder and make an Extension class? Well, because you are sharing your bundle and you want to make it very easy for other people to control this value. So, then you create an AppExtension, with this code:

$container->setParameter('app.comments', 10);

And you remove the "app.comments" part from config.yml. Now, you have EXACTLY the same thing as before, and it's actually still not quite controllable by your user. So, you finally go all the way to your solution, where you create a "comments" value that can be configured by the user. Your AppExtension and Configuration will look exactly like what you have. And in config.yml, you will have:

app:
    comments: 10

So, now I'll answer your questions :)

1) Yes, you can set a parameter directly with only an Extension class. That's the solution I show above with $container->setParameter('app.comments', 10); But, if you're just doing this, why not set the parameter in a simple configuration file (like config.yml)?

2) In your setup, yes, you must have an app key with a comments key below it in order for all of this to work. But, two important things. First, the fact that we have an "app" key and a "comments" key below it has absolutely nothing to do with the fact that an "app.comments" parameter is finally set. The "app" in config.yml is what tells Symfony that the configuration below it is passed to the "App"Extension class. The "comments" is then passed to that class, which is why you're referencing "comments" in your AppExtension. In other words, you could have "foobar: 10" in config.yml and still set a parameter called app.comments, as long as you updated your Configuration and AppExtension files in 1 spot each. Second, you could omit the config.yml stuff completely if you gave the "comments" configuration key a default value in the Configuration class. You could set this to default to 10.

3) About Twig, yes! First, passing a value from a controller to a template is always the simplest method. But, there are several ways to create "global variables" in Twig. One of them is simply in config.yml:

twig:
    globals:
        comments: 10

If you did this, you could use code like {% for i..comments %} in Twig and it would work. This does not set any "dependency injection parameters" - because we don't need that in this case.

Phew! How does this all sound?

Thank you so much for a detailed answer, makes a lot of sense. Out of curiosity I was using the Extension class just to play around and get an understanding of how things work.

Once again many thanks for the wonderful explanation.