That sounds do-able for TwigExtension; I suppose I just wasn't able to do that in FrameworkExtension because the default value is the inverse of kernel.debug :)
Thanks! On Thu, Feb 17, 2011 at 7:14 PM, Christophe COEVOET <[email protected]> wrote: > Le 18/02/2011 01:00, Jeremy Mikola a écrit : > > TwigExtension's twig.xml file defines the default twig.options parameter >> based on the values of several kernel parameters: >> >> <parameter key="twig.options" type="collection"> >> <parameter key="charset">%kernel.charset%</parameter> >> <parameter key="debug">%kernel.debug%</parameter> >> <parameter key="cache">%kernel.cache_dir%/twig</parameter> >> </parameter> >> >> I'm currently in the process of refactoring TwigExtension to use Johannes' >> config builder (nearly done, in fact). I recall previous discussions in IRC >> where there was common agreement that option defaults should be specified in >> the configuration tree. The benefit of doing so will become especially >> clear once we start generating config documentation from the trees. At the >> same time, Ryan Weaver was leading a crusade against calling getParameter() >> in Extension classes, as it removes the ability to override parameters later >> and trust ResolveParameterPlaceHoldersPass to do its job at the proper time. >> >> I'd like to know if this is a legitimate concern for the kernel >> parameters. I know it's not for kernel.debug (which is set when the kernel >> is constructed), and I used that to my advantage in refactoring >> FrameworkExtension (it's a default value for a node in the config tree). >> Are kernel.charset and kernel.cache_dir equally safe to fetch early? If >> not, I'm afraid we'll have to keep those default values in twig.xml. >> >> -- >> jeremy mikola >> > You can use the placeholder syntax for default values in the Configuration > class as the resolution will be done after the extensions are called so this > values will be in the container (same as loading them from the XML file). > > -- > Christophe | Stof > > -- > If you want to report a vulnerability issue on symfony, please send it to > security at symfony-project.com > > You received this message because you are subscribed to the Google > Groups "symfony developers" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/symfony-devs?hl=en > -- jeremy mikola -- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.com You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en
