http://www.w3.org/TR/1999/REC-xpath-19991116#section-Introduction

This may provide a reasonable way to deal with the class attribute value; a has-token(token[, string]) function may be easier to read than some regular-expression mess.

(a) Genshi could add support for the XPath 2 matches() function, which would allow you to match a class name on word boundaries using regular expressions.

(b) Providing an extended XPath engine that would also support the “elem#id” and “elem.class” syntax that is well-known from CSS selectors. Similar to what jQuery does.

Please do post any match template examples that aren’t well suited for XPath to the Genshi mailing list, so we can work on addressing them.

Aaron: Perhaps what’s needed is an extension mechanism to easily add functions for the paths (probably with some common additions like the use of split that you’re suggesting).

I like the XPath syntax in general for what it specifies, but I agree that there are cases where you need to select something outside the realm of what XPath gives you.

def has_class(item, classname):
return classname in (item.attrib.get(’class’, ”).split(’ ‘))

XPath doesn’t seem to handle the fact that class is actually a space-separated list of class names very well.

We have discussed how this could be implemented, and one obvious solution would be to actually provide *two* plugin classes (one for markup templates and one for text templates). Then you’d use something like “genshi-text:myapp.foo.templates” to specify the template in @expose. That doesn’t seem all that elegant.

The other option may be to switch to text templates implicitly if the output format is set to “text”. I’m not sure whether that’s a good idea, as it is not really explicit.

Input from TG wizards very much welcome!

In any case, better support for Genshi in TG is going to require some improvements of the plugin API in the long term, such as adding search paths, not having to hardcode the filename extension, and some way of selecting a template type.