tw2.experimental

[Paul Johnston]

Hi,

I've just updated the code a bit. Now all the unit tests are passing,
and the widget browser is working, with the instance-per-request
model.

http://bitbucket.org/paj/tw2core/
http://bitbucket.org/paj/tw2devtools/
http://bitbucket.org/paj/tw2forms/

Plans from here...
Rename tw namespace to tw2, so you can have tw and tw2 installed at
the same time
Validation
Declarative definition
Tutorial that shows how to do it with a simple WSGI app

If anyone wants to help, drop me a line.

Paul

[Paul Johnston]

Hi,

Ok, been a lot of progress, been sat in Vientienne, Laos with not a
lot else to do.

The tw2 repositories on bitbucket have been updated. They now use the
tw2 namespace, and both validation and declarative instantiation are
basically working.

The sphinx documentation is online, including the beginnings of a WSGI
tutorial, at http://pajhome.org.uk/tw2/
The widget browser is also online, at http://pajhome.org.uk:8000/

At this point, you could reasonably build an app with tw2. There's
still a whole load on the todo list, but I'm happy the general widget-
per-request model works. I don't think I'll be doing much more work on
tw0.9.

I'd really like for some people to try this out and give some
feedback.

Paul

[percious]

This is really great news.

I am interested in experimenting with building Sprox around your new
core, and seeing if there are any performance benefits. My main
concern with TW right now is performance...

cheers.
-chris

On Jun 17, 4:41 am, Paul Johnston <paul....@gmail.com> wrote:
> Hi,
>
> Ok, been a lot of progress, been sat in Vientienne, Laos with not a
> lot else to do.
>
> The tw2 repositories on bitbucket have been updated. They now use the
> tw2 namespace, and both validation and declarative instantiation are
> basically working.
>
> The sphinx documentation is online, including the beginnings of a WSGI

> tutorial, athttp://pajhome.org.uk/tw2/
> The widget browser is also online, athttp://pajhome.org.uk:8000/

[percious]

Okay, i started playing with this and got it to work in tg2. It was
really not too painful to do so. I created a branch for tg2 to
support this at bitbucket: http://perc...@bitbucket.org/percious/tg-21-tw2/

I needed to change the tw2 codebase slightly. This was to add an
optional "state" variable to the validate function. This makes the
tw2 code match that of formencode, providing an opaque interface for
both. Also, i think the state variable may come in handy down the
future, so it is likely to be a nice contribution. Here is the diff:

--- a/tw2/core/widgets.py Sun Jun 21 20:04:25 2009 +0700
+++ b/tw2/core/widgets.py Wed Jun 24 10:50:27 2009 -0600
@@ -194,7 +194,7 @@
return mw.engines.render(self.template, displays_on,
vars)

@classmethod
- def validate(cls, params):
+ def validate(cls, params, state=None):
"""
Validate form input. This should always be called on a class.
It
either returns the validated data, or raises a

Here is what my TG2 code looks like:

app_cfg.py:

<add>
base_config.use_toscawidgets2

root.py:

class RootController(TGController):

...

@expose('tw2test.templates.tw2')
def tw2(self, **kw):
if tmpl_context.validation_exception:
tmpl_context.widget =
tmpl_context.validation_exception.widget
else:
tmpl_context.widget = MyForm
return dict(values=kw)

@validate(MyForm, error_handler=tw2)
@expose()
def tw2post(self, **kw):
return str(kw)


The tw2 function is pretty ugly if you ask me. Is there something we
could do instead to tell the MyForm widget to display error messages
other than just replacing it with the exception's widget? I think
there is room for improvement here.

Here is a screenshot of it actually working!

http://imagebin.ca/view/uyjB31.html

Awesome job Paul. I'm going to work on some benchmarks now to see if
it really is an issue creating one widget instance per request. Since
tw2 and tw can run on the same project, it will at least be a fair
battle. I'll post results to a separate thread.

cheers.
-chris

[percious]

correction, that should be:

base_config.use_toscawidgets2 = True

cheers.
-chris

On Jun 24, 10:54 am, percious <ch...@percious.com> wrote:
> Okay, i started playing with this and got it to work in tg2.  It was
> really not too painful to do so.  I created a branch for tg2 to

> support this at bitbucket: http://perci...@bitbucket.org/percious/tg-21-tw2/

[percious]

sorry guys, the link to the bitbucket is:

http://bitbucket.org/percious/tg-21-tw2/

On Jun 24, 10:54 am, percious <ch...@percious.com> wrote:

> Okay, i started playing with this and got it to work in tg2.  It was
> really not too painful to do so.  I created a branch for tg2 to

> support this at bitbucket: http://perci...@bitbucket.org/percious/tg-21-tw2/

[Paul Johnston]

Hi,

> Okay, i started playing with this and got it to work in tg2.  It was

Awesome! What would be really fab is if you could write a "Using tw2
with tg2" tutorial. It doesn't have to go far into things, just
showing people how to get going, and do a form with validation.

>  I needed to change the tw2 codebase slightly.  This was to add an
> optional "state" variable to the validate function.  This makes the

This sounds like a good change, I will apply it in due course.

> The tw2 function is pretty ugly if you ask me.  Is there something we
> could do instead to tell the MyForm widget to display error messages

The latest tip already does this. A validation failure is stored in
request local storage, and the display method detects this and uses
that widget.

Really pleased to hear how you got on,

Paul

[Michael Brickenstein]

Hi Paul!

I think, the original widget browser had some very value features:
E.g. the read-eval-print-loop. Did you consider porting it, instead of
writing a new one?

I found your code very readable.

Michael

[Paul Johnston]

Hi,

Ok, the state variable is in. It doesn't do anything for now, just
there for TG compatibility.

Regarding the widget browser, I will at some point be raiding the old
widget browser for ideas and code. I hadn't so far, because I
disagreed with the way the old one works. I think the most important
bit is a page for each module that gives a short summary with an
inline demo.

Paul

[Michael Brickenstein]

Hi!
I don't know, if you have done this.
But I wish an "explicit is better than implicit" for TW:

Automatic evaluation of callables arguments should be removed.
Instead we should have
something like
delayed(callable)
constructing something, which TW recognizes to be evaluated
at display time.
Michael

[Paul Johnston]

Hi,

I agree completely. TW2 uses a "Deferred" to mark a parameter as a
callable.

Paul

[percious]

The docs @http://pajhome.org.uk/tw2/ appear not to be working.

cheers.
-chris

[percious]

tw2.forms now has 100% code coverage in my branch.

Also, every widget in tw2.forms is written both in mako and genshi.

Lastly, the output of the each template set is compared to a known
xml, and therefore they should be consistent.

If anyone wants to write cheetah templates, I can direct you, but mako
is fast enough for my purposes.

I found a number of small bugs in the last 10% of coverage testing,
always the hardest part to test.

I think the form stuff at least is ready for prime time. Now to head
on to tw2.core for some more testing.

enjoy.
-chris

On Jul 8, 8:53 pm, percious <ch...@percious.com> wrote:
> The docs @http://pajhome.org.uk/tw2/appear not to be working.

[Paul Johnston]

Hi,

> tw2.forms now has 100% code coverage in my branch.
> Also, every widget in tw2.forms is written both in mako and genshi.

All this progress is awesome. Thanks for your input.

What I'd like to do from here is go over all you changes and integrate
them with my branches. Not sure when exactly I'm going to do this, but
bear with me :-) If I'm happy we're working the same direction, then
lets start working on the same branch. As I mentioned in the email to
you/Mike, one concern was the amount of mako support code - can we use
TGPlugin from Mako as Mike suggested?

Docs are now at: http://toscawidgets.org/documentation/tw2.core/

An obvious next step is tutorials for Pylons and TG2. I think forcing
people to use an alternate TG2 branch for this might turn people off,
so if we can figure a tutorial that has a slightly hacky step to
enable TW2, that might be preferable. Or a clean one is even
better :-)

Thanks again for the input,

Paul

[percious]

Hey, i'll make myself available any time on Saturday (MDT) that you
like if you want to chat online about the prospects for TW2. I'll
make myself available via IRC for anyone interested in this topic.

About the mako support. I am not really excited about Bufffet in
general. It seems like you went this route in general. Ben decided
this was not a good plan in Pylons, and chose support it by writing a
function. I have to agree with this approach, and this is how I have
implemented it. Also, i think _get_adaptor_renderer is a total waste
of computation, so basically there is no support for this in mako.
it's so easy to just do: ${child_widget.display() |n} in mako i cannot
fathom why such a function would be worth the CPU cycles. Also,
escaping HTML is way more expensive in mako then just skipping over it
with "| n".

Tw2 will be supported in TG2 one way or another. I sent out a pull
request to all of the major contribs on TG2. Just waiting for replies
for diplomatic reasons. People are just afraid of jerking the general
public around about widgets and whatnot. We need to make the
transition smooth. TW is a brand, we need to decide to keep it or
not. Sprox went through the same thing....

I'm having fun working on this and hopefully we can continue to work
together.

cheers.
-chris

[Paul Johnston]

Chris,

I've had a look through your changes and they look good. I've granted
you push access to all my tw2 repositories on bitbucket, do go ahead
and push your changes. Can you make a few of changes:

1) Lets put css_class on the Widget class in tw2.core
2) Make rendering_extension_lookup a configurable option
3) Add a paragraph to the docs about multiple template support

You've obviously considered the Buffet issue more than me, I'll go
with your take. My feeling was to minimize template related code in
tw2, but if the benefits make it worthwhile, lets keep it in. Is
dottedtemplatelookup just used for Mako? Perhaps we could put the code
in mako_util.py, so all Mako stuff is in one file.

Aw, criticism of my precious _get_template_renderer function. It
hurts :-) I'm not dead set on keeping this, but I am keen that we keep
the tw1 property of being able to arbitrarily nest widgets of
different template types. If you can figure out a more performant way
of doing this, it's welcome. I don't understand the changes you've
made to EngineManager, apart from adding the call to get_engine_name.
Did you have problems with the previous code?

Regarding, CheckBox and the "if in __dict__" code. That should have
been self.safe_modify('attrs'). My current reckoning is that whenever
prepare modifies a mutable class attribute, it should copy it to an
instance attribute. The user needs to be aware that if they set an
instance attribute to a mutable, that mutable may get updated. This
may not be the most performant approach, but it's simple and safe. If
we go for a more performant approach, we should think carefully about
any undesired side effects. And we should put this in the docs!

Thanks for the input. I will endeavour to come on IRC on Saturday. I'm
in GMT+7, and will be in Vang Vieng, where the alcohol flows freely,
so it may be a little tricky. I'll have a think and try to establish a
precise time I'll definitely be on (and composmentis :-) All the best,

Paul

[Alberto Valverde]

Paul Johnston wrote:
> (...)

>
> You've obviously considered the Buffet issue more than me, I'll go
> with your take. My feeling was to minimize template related code in
> tw2, but if the benefits make it worthwhile, lets keep it in. Is
> dottedtemplatelookup just used for Mako? Perhaps we could put the code
> in mako_util.py, so all Mako stuff is in one file.
>
> Aw, criticism of my precious _get_template_renderer function. It
> hurts :-) I'm not dead set on keeping this, but I am keen that we keep
> the tw1 property of being able to arbitrarily nest widgets of
> different template types. If you can figure out a more performant way
> of doing this, it's welcome. I don't understand the changes you've
> made to EngineManager, apart from adding the call to get_engine_name.
> Did you have problems with the previous code?
>

I'd like to chime in to suggest on of the design-constraints I thought
of when fantasizing about tw2 before tw2 existed:

Why not ditch away all the templating functionality out of tw2 and
standardize on a a good 'ol (unicode please) string as output? This
would remove a lot of code and complexity and offer the best
flexibility: Use whatever method you want to build a damn string. :)

The only downside I can think of is that Genshi widgets will *crawl*
(due to all the de/serializing going on when rendering nested widgets)
but it shouldn't be a problem in practice to avoid genshi since I've
never found that it's full power (xincludes, py:match, etc...) is
needed to output a small chunk of markup, only when building a "full"
page that you want to easily extend. If this is ever a problem one
could always use chameleon.genshi for speed.

Alberto

[Diez B. Roggisch]

>
> The only downside I can think of is that Genshi widgets will *crawl*
> (due to all the de/serializing going on when rendering nested widgets)
> but it shouldn't be a problem in practice to avoid genshi since I've
> never found that it's full power (xincludes, py:match, etc...) is
> needed to output a small chunk of markup, only when building a "full"
> page that you want to easily extend. If this is ever a problem one
> could always use chameleon.genshi for speed.

To me there are a few more advantages to genshi: they are XML-based, and thus
prevent me from writing malformed templates. They also allow to have a
rendering-option that lets you put out various kinds of HTML-dialects with
just one source template. And last but not least they allow for easy
template-i18n, because they can use filters on their streams.

All this would be lost on a pure-string solution.

Diez

[Christoph Zwerschke]

Diez B. Roggisch schrieb:

> To me there are a few more advantages to genshi: they are XML-based, and thus
> prevent me from writing malformed templates. They also allow to have a
> rendering-option that lets you put out various kinds of HTML-dialects with
> just one source template. And last but not least they allow for easy
> template-i18n, because they can use filters on their streams.
>
> All this would be lost on a pure-string solution.

I fully agree with Diez on that. I really liked the possibility to
choose the HTML/XHMTL dialect with one config setting in TG1/Kid. With
Genshi, this became already more difficult and has several glitches
(http://trac.turbogears.org/ticket/2287). I'd rather see these issues
(e.g. http://toscawidgets.org/trac/tw/ticket/40) fixed instead of
getting things even worse in this respect.

-- Christoph

[percious]

Alberto,

Wow, I was hoping to get some feedback from you on all this stuff
going on. I have been discussing the possibility of being "template
unaware" with Chris Mcdonough on IRC over the past week or so, but I
am afraid I just don't "get" it.

Do you have a code example of how this would work?

cheers.
-chris

[percious]

On Jul 13, 12:10 am, Paul Johnston <paul....@gmail.com> wrote:
> Chris,
>
> I've had a look through your changes and they look good. I've granted
> you push access to all my tw2 repositories on bitbucket, do go ahead
> and push your changes. Can you make a few of changes:

Awesome. Thanks.

>
> 1) Lets put css_class on the Widget class in tw2.core

Agree.

> 2) Make rendering_extension_lookup a configurable option

Shoot. I just wrote a whole response to this and then I realized what
you meant. I like this idea. This way you can define which
extensions go with which template language. Brilliant. Now I can
use .mako again. (I _hate_ .mak)

> 3) Add a paragraph to the docs about multiple template support

No issues there.

>
> You've obviously considered the Buffet issue more than me, I'll go
> with your take. My feeling was to minimize template related code in
> tw2, but if the benefits make it worthwhile, lets keep it in. Is
> dottedtemplatelookup just used for Mako? Perhaps we could put the code
> in mako_util.py, so all Mako stuff is in one file.

dottedtemplate lookup is indeed only for mako at the moment, but could
be amended to include other template language lookups in the future.
the tG2 codebase has genshi and mako in there for instance. I chose
to use your implementation of buffet for genshi however.

>
> Aw, criticism of my precious _get_template_renderer function. It
> hurts :-) I'm not dead set on keeping this, but I am keen that we keep
> the tw1 property of being able to arbitrarily nest widgets of
> different template types. If you can figure out a more performant way
> of doing this, it's welcome. I don't understand the changes you've
> made to EngineManager, apart from adding the call to get_engine_name.
> Did you have problems with the previous code?

Actually, we sort of removed this arbitrary nesting widgets thing in
0.9.6/7. It caused a few headaches, but really, there were only a few
templates that needed to be changed. I don't think it is actually
terribly hard to express to widget developers that they need to escape
nested widget calls in their templates, but maybe I am wrong.

>
> Regarding, CheckBox and the "if in __dict__" code. That should have
> been self.safe_modify('attrs'). My current reckoning is that whenever
> prepare modifies a mutable class attribute, it should copy it to an
> instance attribute. The user needs to be aware that if they set an
> instance attribute to a mutable, that mutable may get updated. This
> may not be the most performant approach, but it's simple and safe. If
> we go for a more performant approach, we should think carefully about
> any undesired side effects. And we should put this in the docs!

I'd be happy to leave documenting this "feature" up to you, and
reviewing said docs.

>
> Thanks for the input. I will endeavour to come on IRC on Saturday. I'm
> in GMT+7, and will be in Vang Vieng, where the alcohol flows freely,
> so it may be a little tricky. I'll have a think and try to establish a
> precise time I'll definitely be on (and composmentis :-) All the best,

Sorry if I missed you on IRC. It turned out that my carpal tunnel
started acting up, and it was better for me to take a family weekend
rather than try and push thru the pain.

cheers.
-chris

[percious]

1) 2) 3) are completed.

[Paul Johnston]

Hi,

> I believe in the adage, release early, release often, and it helps me
> get TW2 into TG2 politically if it has had a release. Right now there

The problem with this is maintaining backward-compatibility. If we're
absolutely clear that this is alpha and backward-compatibility is not
guaranteed, I'm ok with it.

> > Some magic is necessary to support the instance per request model -

> Could we not detect if display_on was cheetah an somehow adjust for
> cheetah in some manner?

I think so. The issue is that when you do ${w.children.mychild.myattr}
if w or mychild have __call__ then Cheetah autocalls them. So if
__call__ returns self on Cheetah and calls display on other templates,
I think we're ok. This magic needs to be documented in detail (as the
subclassing magic already is).

> Also, could we consistently detect whether or not we had already
> subclassed?

I had a go at this and it turned out to be harder than I expected. We
certainly should aim to do that, but it needs to be a carefully
thought out change with lots of unit tests.

> long as we can support FE backwards, that's enough for me. How about
> making FE a dependency tho?

Can I ask the reasons for this? My usual thinking is to minimise
dependencies, and my thinking is that most users would use the built-
in validation, and just the odd person would use FormEncode, when they
want a validator that FE does particularly well.

> Actually, we sort of removed this arbitrary nesting widgets thing in
> 0.9.6/7.  It caused a few headaches, but really, there were only a few

My main thinking is that a user should be able to use any template
language they like for the page, and be able to include widgets in it.
Also, the less supported libraries will probably only have templates
in a single language. e.g. dynforms/yui only have Genshi for now, and
you need to be able to include them in forms. At this point, I'm
getting a bit worried that we'll lose useful functionality for the
sake of performance. I'd like to keep this for now. Feel free to
refactor the code so that mako-mako case is the most performant, but
lets keep the functionality the same.

> Sorry if I missed you on IRC.  It turned out that my carpal tunnel
> started acting up, and it was better for me to take a family weekend
> rather than try and push thru the pain.

Ah, misunderstanding of which Saturday you meant. I'm just about to do
a lot of trip planning and flight booking; I'll suggest a meeting time
when I've done that.

Paul

[percious]

> > I believe in the adage, release early, release often, and it helps me
> > get TW2 into TG2 politically if it has had a release.  Right now there
>
> The problem with this is maintaining backward-compatibility. If we're
> absolutely clear that this is alpha and backward-compatibility is not
> guaranteed, I'm ok with it.

I'm totally Okay with saying we break backwards compat. Acceptance
into the TG2 chain will probably depend on an alpha-at-minimum
release.

> > long as we can support FE backwards, that's enough for me.  How about
> > making FE a dependency tho?
>
> Can I ask the reasons for this? My usual thinking is to minimise
> dependencies, and my thinking is that most users would use the built-
> in validation, and just the odd person would use FormEncode, when they
> want a validator that FE does particularly well.

reasoning is to make coverage testing easier, which may/may not be a
good reason, but I can't understand why we wouldn't make FE a dep
since it is such a small and also well documented package. I took a
stab at covering the "import" statements, look for a "_test" test.

> > Actually, we sort of removed this arbitrary nesting widgets thing in
> > 0.9.6/7.  It caused a few headaches, but really, there were only a few
>
> My main thinking is that a user should be able to use any template
> language they like for the page, and be able to include widgets in it.
> Also, the less supported libraries will probably only have templates
> in a single language. e.g. dynforms/yui only have Genshi for now, and
> you need to be able to include them in forms. At this point, I'm
> getting a bit worried that we'll lose useful functionality for the
> sake of performance. I'd like to keep this for now. Feel free to
> refactor the code so that mako-mako case is the most performant, but
> lets keep the functionality the same.
>

I think I can live with this compromise. As long as we keep mako
fast, I care very little about what happens with genshi or the other
template languages. We just have to realize that mako has this
exception which makes it work a bit differently than the others.

Today I got resources working in a TG2 context, so I have pretty much
every bit of functionality I require for it to work with my projects.
I also plan to modify Sprox to also support TW2 in the near future.

I added tw2.dojo to my bitbucket. You might want to take a look at
base.py to see how DojoLinkMixin is implemented. I used the
techniques described in: http://percious.com/blog/archives/20 I am
hoping we can add these techniques to tw2.yui, in addition to YUI3
stuff. I have a project I'm doing with YUI3 exclusively.

cheers.
-chris

[Michael Brickenstein]

Hi Paul!

In general:

Can you compare tw2 to django newforms?
Which is the audience of tw2?
Honestly, I found the strength of tw to lie in environments like
RUM or sprox, as it encapsulates everything.

Michael

[Paul Johnston]

Hi,

> I'm totally Okay with saying we break backwards compat.  Acceptance
> into the TG2 chain will probably depend on an alpha-at-minimum
> release.

Well, I'm ok with this, but we should check with Alberto before doing
so. I think we should release as 2.0-alpha1.

On reflection, I'm totally non-fussed about TG2 support. You can stack
arbitrary middleware in TG2, so it's easy to just put instructions for
this in the tutorial, and we don't rely on any changes in TG2. I'd say
an "enable_tw2" config option is for some way down the line.

> reasoning is to make coverage testing easier, which may/may not be a

I see... we probably both have FE installed and are testing with it
present. There may be bugs that appear when it's absent. On the other
hand, for Google App Engine support, we need to really minimize
dependencies. My thinking is still to not have an FE dependency.

> I think I can live with this compromise.  As long as we keep mako
> fast, I care very little about what happens with genshi or the other
> template languages.  We just have to realize that mako has this
> exception which makes it work a bit differently than the others.

Cool, just make sure all this is documented!

Paul

[Paul Johnston]

Hi,

> Can you compare tw2 to django newforms?

Definitely, they're aiming at a similar space. I first looked at
newforms back in March, before I started tw2.exp. At that time it seemed
very much focused on the simpler widgets, basically forms, not the
fancier widgets like dynforms, dojo, yui, etc. I see they've now
introduced a concept like resources, or maybe I missed this first time
round. We should definitely keep an eye on newforms and keep in touch
with the Django guys. What would be great is if we found someone to be
the "Django man" for tw2.

> Which is the audience of tw2?

Now - users of tw1. Later - anyone developing an interactive web app in
Python.

> Honestly, I found the strength of tw to lie in environments like
> RUM or sprox, as it encapsulates everything.

Having something like rum/sprox is definitely important. I have a
feeling we should aim fo a single dbwidgets library, and this is
something we should start discussing soon. I'm still focused on other
things for now, but if you or Chris would like to kick off by doing a
port of sprox/rum, or just discussing ideas on the list, that'd be great.

Paul

[Alberto Valverde]

percious wrote:
> Alberto,
>
> Wow, I was hoping to get some feedback from you on all this stuff
> going on. I have been discussing the possibility of being "template
> unaware" with Chris Mcdonough on IRC over the past week or so, but I
> am afraid I just don't "get" it.
>
> Do you have a code example of how this would work?

Yep:

def display(...):
.....
return u"<div ...>....</div>"

or:

def display(...):
....
return render_with_mako('some_template.mako', ....)

or .... any method you want to create an unicode string.

Alberto

[Paul Johnston]

Hi,
> def display(...):

> return u"<div ...>....</div>"
>

If we did this, then every time you displayed a widget in a Genshi
template you'd have to do ${Markup(widget.display())}

I reckon we stick with what we've got, give or take minor tweaks for
performance.

Paul

[Michael Brickenstein]

Hi!

As a Genshi user, I can tell you:
writing Markup(...)
is a no brainer.

However, all this "best engine stuff" did cost a lot of time to me.
I wish TW/TW2 to be robust.
Michael

[Jonathan Schemoul]

Maybe, but I prefer to receive xml streams and no markup soup in my templates (you now, genshi tries to validate that soup)...

And genshi is great for that.

Jon

[Michael Brickenstein]

Hi Jon!

You have a good point.
I think the best thing is, if this unicode represents an XML-document
or at least XHTML.

Above, the question was raised, how to generate html:
This should not be a matter of the widget. I should always do XHTML,
everything clean and manipulateable.

Transformation to HTML should be done by some middleware layer.

Michael

On 27 Jul., 11:07, Jonathan Schemoul <jonathan.schem...@gmail.com>
wrote:

> Maybe, but I prefer to receive xml streams and no markup soup in my
> templates (you now, genshi tries to validate that soup)...
>
> And genshi is great for that.
>
> Jon
>
> On Mon, Jul 27, 2009 at 9:37 AM, Michael Brickenstein

> <brickenst...@mfo.de>wrote: