Edgewall Software

Opened 18 years ago

Last modified 13 years ago

#59 new enhancement

Docs should explain what python types are handled in expressions

Reported by: talin@… Owned by: cmlenz
Priority: trivial Milestone:
Component: Documentation Version: 0.2
Keywords: Cc:

Description

One difference I notice between Genshi and Kid is that Genshi appears (AFAICT) to expect that the result of a template expression will be a string, wherease Kid automagically converts lists, element trees, and other structured types into a string. For example, in Kid I can pass a list of elementTree nodes, and Kid will convert this into the appropriate markup.

If Genshi isn't going to support automatic conversion, then the docs should clarify exactly what is the expected result of a template expression.

Change History (2)

comment:1 Changed 18 years ago by cmlenz

I definitely agree that this needs to be documented.

Genshi should in fact flatten iterable objects that are the result of template expressions. However, Genshi doesn't natively know about ElementTree objects, so those aren't handled as in Kid. There's an adapter function genshi.plugin that can be used to convert ElementTree objects into Genshi markup streams. Maybe it should be moved into genshi.util so that it's more natural for use outside of the template engine plugin.

comment:2 Changed 14 years ago by Carsten Klein <carsten.klein@…>

Since Genshi knows about its own elements such as Markup, Element and Node, why not leave the user with the responsibility to write adapter classes for these when returning lists from expressions and so on.

Because, as I see it, registering such adapter classes with the engine as plugins would yield additional overhead on overall processing speed.

However, I strongly vote for being able to return iterables from expressions and have genshi recursively iterate over it when rendering the template.

This could be achieved by wrapping the expression result into a Markup derived object, that when called for rendering itself would iterate over the wrapped iterable.

Even the changes to the code base would be minimal, I presume.

Note: See TracTickets for help on using tickets.