On 13 December 2012 22:45, Olemis Lang <[email protected]> wrote: > Subjects to be discussed (IRC summary) > > 1. whethet it's better to use c = self.env.config ; > application_short = c.get('labels', 'application_short', "Bloodhound") > ; ... instead of trac.config.options >
I have evaluated the config.options and as elegant as that is, there is no way to specify defaults that way. That would mean that we would have to change trac.ini during upgrade of older installations and is not as robust agains users mistakes when changing the config file manually. > > 2. on the subject of where to put labels data maybe it should be > made available in request callbacks (just like req.chrome works at the > moment ;) > BH uses it's own templates from bloodhound_them together with original Trac request handlers. Current approach works for this combination without a need to change Trac codebase. But we could move the labels dict from request.chrome to data inside BloodhoundTheme.post_process_request(): data['labels'] = self._get_whitelabelling() if that is considered as a more appropriate solution. > 3. there's another observation and it is to instantiate req. chrome > inside theme's post_process_request post only if > * bloodhound theme is enabled and active > * request handler actually needs it ... e.g. chrome should be > useless most of the time for /rpc requests and alike . > That's exactly why instantiation is lazy in first place . > > Sounds sensible but isn't "chrome" a Trac thingy? AFAICT it is already there when request lifecycle methods form BloodhoundTheme are called. Does moving labels from "chrome" to "data" help here in any way? > -- > Regards, > > Olemis. > > Blog ES: http://simelo-es.blogspot.com/ > Blog EN: http://simelo-en.blogspot.com/ > > Featured article: >
