Re: Re: An HTML Entry Parser

will wrote:

> I don't know if I would do that. I think we should just build an
> alternate renderer instead.

Ehem, Will, you are right :) A renderer plugin (as I've done lots of 
them already) is as easy as:

--------------
from Pyblosxom.renderers.blosxom import BlosxomRenderer

class SomeRendererName(RendererBase):
    def _getFlavour(self, taste):
        # Override it your way here
        pass

def cb_renderer(args):
    req = args['request']
    conf = req.getConfiguration()

    if #specify your condition if you need to 'activate' it:
         return SomeRendererName(req, conf.get('stdoutput', sys.stdout))
----------

Other examples are:
http://roughingit.subtlehints.net/code/comments_to_rss_two.py.html
http://roughingit.subtlehints.net/code/rss_two_renderer.py.html


And the most nifty one is at http://roughingit.wari.org/Main.py.html 
which I modified the RendererBase.showHeaders() this way:
---------------
from Pyblosxom.renderers import base

def thisShowHeaders(self):
        for x in self._header.keys():
                self._out.response.setHeader(x,
                        self._header[x])
# On the fly modification of methods in a class
base.RendererBase.showHeaders = thisShowHeaders
----------
And I also emulated CGI fields this way:
---------------
class CGIEmulator:
        def __init__(self, value):
                self.value = value
------------------
which is used this way:
--------------
                form = {}
                # CGI fields work differently in WebKit
                for x in trans.request().fields().items():
                        form[x[0]] = CGIEmulator(x[1])
                request['form'] = form
-------------

Having a flavour callback may be better, or might not be a good thing, 
it's something we can figure out later, but the advantages is that it is 
easier to reuse when it comes to subclassing the BlosxomRenderer.