Re: glossary formatter

Lee Joramo wrote:
> Way back in March, I started to investigate pyblosxom as a replacement 
> for Radio Userland. Of course, I got side tracked on this project, but I 
> am back and very close to moving to pyblosxom.

What can I say? Welcome back :)

> One of the things that I did while testing pyblosxom in March was 
> creating a Glossary Preformatter to replace the "shortcuts" feature 
> found in Radio. I posted the code to this list and there was some good 
> feed back on improvements.

Yes, more or less, our plugin system have matured, between 0.6 and 0.7 
beta1, there's a lot of changes here and there.

> I have now tried to work with pyblosxom-0.7beta1, but have not been able 
> to get my Glossary code to work. Reviewing this mailing list and the dev 
> list and the various pyblosxom web sites, I see that a PostFormatter 
> feature was added partly in response to my Glossary formatter.

Postformatters are things that happens after preformatters have done 
their job, reading the file, we have a few preformatters now, and they 
are all plugins now, they should be placed in the plugin directory 
instead of the preformatters directory. Some preformatters will run 
postformatters, others will not. For example, the .txt, .txtl, .rst and 
.wiki file readers (which we call entryparsers) will run postformatters, 
the entryparser that reads *.py files will not because it doesn't make 
sense to do so. Also, preformatters only happens on .txt files, but not 
the rest. Some entryparser plugins are preformatters as well, which 
means to say that a .txt file with the line '#parser wiki' has the same 
effect of reading a .wiki file. That's how extensible the plugin system is.

> I have tried to figure this out, but am now fairly lost. Below is the 
> original code, what changes do I need to make? How do I set this up to 
> run on all pages? Is there a document that explains all of this that I 
> have missed?

Yeah, sorry about that, but I think we've thrown out compatibility for 
flexibility, and this means that if you code your plugin as a 
postformatter, then you've have your code running on every filetype and 
preformatter without caring about how to read the data from the file. 
Below is a pseudocode of how your code would look like as a 
postformatter plugin.
-------------
def getGlossary():
     # This is where you gather your glossary tuple/dict, either from a
     # file or just a built in list
     pass

def cb_postformat(args):
     text = args['entry_data']['body']
     glossary = getGlossary()
     # Do your stuff with glossary and text
-------------
Documentation of the postformat plugin can be found here (minimal docs 
that is) 
http://roughingit.subtlehints.net/doc/public/ReadMeForPlugins-module.html#cb_postformat

As you can see, there's no more crummy object to subclass from, you can 
have you plugin working with just functions here.

BTW, If you have a cache configured, it is better to delete it, as the 
data from postformat will be cached, and will not be called again until 
the original entry is 'freshened'.

-- 
Regards: Wari Wahab
RoughingIT - http://roughingit.subtlehints.net
PyBlosxom  - http://roughingit.subtlehints.net/pyblosxom



-------------------------------------------------------
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/psa00100006ave/direct;at.asp_061203_01/01