incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Koželj <>
Subject Re: [Whitelabeling] Quick assessment of (current) whitelabelling implementation .
Date Mon, 17 Dec 2012 07:38:11 GMT
On 13 December 2012 22:45, Olemis Lang <> 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 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 to data inside

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:
> Blog EN:
> Featured article:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message