Re: Bug in overriding configuration variables in config.flav?

Wari Wahab <wari-Yu9E6tdDWSZWk0Htik3J/[email protected]>
Newsgroups gmane.comp.web.pyblosxom.user
Message-ID <[email protected]>
* Robert Wall <[email protected]> [030724 05:54]:
> My configuration of this system is probably somewhat unusual.  The
> problem for me is that I would like to limit the depth and number of
> entries on certain flavours and not others.  

Yup, this is a special use case.

> The overring mechanism should be perfect! (I had tried it once before
> with 0.7beta code but not until Wari suggested it again recently in a
> private e-mail did I try it with CVS code. BTW, Wari the other code
> you suggested worked perfectly).  Unfortuntely the overriding doesn't
> work.  I have created my files config.flav with entries of the form:
> depth 0
> num_entries 999

The real reason why a lot of configuration variables won't work well is
because of the flow in which pyblosxom uses a certain var.

Take for instance, depth, and datadir. You can override them in the
config.flavour files, but the values are actually used much earlier in
the life cycle of pyblosxom, and later you modify.

What can be done is a plugin that runs at cb_startup() and try to read
the configuration overrides there. `depth` and other useful variables
could then be used in the other parts of the life cycle of pyblosxom.
This is how blosxom does it with the config plugin. If someone does this
plugin, I will remove the (rather) out of place code in __getFlavour().

> The code that is reading these entries can be seen on lines 88-94 of
> pyblosxom/Pyblosxom/renderers/blosxom.py and is quoted below:
> [..SNIP..]
> wrap the last expression with int().  A second config.flav file (a
> custom index flavour) I have which relies on two integer values (like
> the example above) is not being working.  I have not yet tracked down
> why this is so.

I though blosxom.py will coerce the type of num_entries into a string
(when using it for a count). But anyway, like I said, this is probably a
better job for a plugin than making the __getFlavours() code more
complex.

> Sorry for the such a long, e-mail.  I hope that this really is a bug
> and not my mistake!

It's a design thing :)


-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.