Wish: <py:call lambda="func">FooBar</py:call> Resulting in func(stream) call

[jacco@…]

Hi there,

I would like to post a wish for new genshi funcionality:

The idea is as follows:

In my XHTML template I would write:

 <py:call lambda="func">
   <h2>
     FooBar
   </h2>
 </py:call>

in python, for example:

 def func(stream):
     return tag.div(tag.p("bogus"), stream, tag.p("bogus")).generate()

This would make the result of

>>  func(stream)

to replace the py:call tag. So in this case resulting in the following html:

  <div>
    <p>bogus</p>
    <h2>
      Foobar
    </h2>
    <p>bogus</p>
  </div>

The advantage is that the argument of func can be any XHTML. The alternative way of doing this:

  ${func(tag.h2("Foobar"))} 

is less readible and less flexible, since we suddenly have to use the tag() way of specifying HTML instead of using proper (X)HTML.

This solution would make very readable html templates. Of course the same thing could be implemented with match templates, but they are not in all cases the easiest and fastest and cleanest and most readable solutions. Furthermore py:call can be resolved while generate()ing and without extra match pass (as far as i understand how genshi works).

Of course the following should also work:

  <h2 py:call="func">
    FooBar
  </h2>

Where he result of func(stream) should be embedded in the h2 in this case yielding:

  <h2>
    <div>
      <p>bogus</p>
      Foobar
      <p>bogus</p>
    </div>
  <h2>

Thanks for your time. Jacco Taal

[hodgestar]

This looks like a useful generic addition. The same result could probably be achieved with match templates but it's obviously wasteful to search through the XML for pieces that need to be transformed when knows explicitly which parts of the stream to look at. I suggest making the suggestion again on the mailing list and seeking some feedback there (I'm a new committer so I'm relatively cautious about adding new features).

Assuming no one on the mailing list convinces me this isn't a good addition I might get around to implementing it but you could speed the whole process up a lot my providing a patch (preferably with tests and documentation updates).

Since adding this shouldn't break any existing templates I'm leaving the milestone at 0.6.1 but since it's a new feature one could make a case for it being deferred to 0.7 (which needs to get released at some point in the not too distant future).

[hodgestar]

Move to milestone 0.9.