Python Buzz Forum - In search of a Pythonic, XML-based Templating Language

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

Python Buzz Forum
In search of a Pythonic, XML-based Templating Language

9 replies on 1 page. Most recent reply: Dec 1, 2004 3:03 PM by Jonathan LaCour

Welcome Guest
Sign In

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 9 replies on 1 page

Ryan Tomayko

Posts: 408
Nickname: rtomayko
Registered: Nov, 2004

Ryan Tomayko is an instance of a human being...

In search of a Pythonic, XML-based Templating Language

Posted: Nov 29, 2004 11:06 PM

Reply

This post originated from an RSS feed registered with Python Buzz by Ryan Tomayko.
Original Post: In search of a Pythonic, XML-based Templating Language Feed Title: Ryan Tomayko (weblog/python) Feed URL: http://tomayko.com/feed/ Feed Description: Entries classified under Python.	Latest Python Buzz Posts Latest Python Buzz Posts by Ryan Tomayko Latest Posts From Ryan Tomayko (weblog/python)

Advertisement

I've been searching for the perfect Python based XML template language. I was happy to find TAL (and specifically, SimpleTAL) a while back but, although neither of us wants to admit it, we've been growing apart for some time now. I spent last week looking for options and, after careful consideration and planning (read: beer and a nap), decided to just build the XML template language I really wanted.

There's at least four billion and nine text based template languages for Python but there aren't a lot of options that fit nicely into the XML tool-chain. Or, if they do fit nicely into the XML tool-chain, they don't fit nicely with Python.

My dreamboat XML template language would combine the pythonicness and simplicity of PTL, the templating features and pipeline-ability of XSLT, and the terseness of Zope's TAL. I'm building it, it's called Kid, and I'm making good progress to be honest.

But I have this overwhelming NIH feeling so I've decided the best thing to do is to run through the current set of tools and take a professional, objective look at why each isn't getting it done for me (i.e. make fun of minor flaws and limitations until I feel better about myself). Herewith, a look at the good and the bad in the Python XML templating space...

Read: In search of a Pythonic, XML-based Templating Language

Glyph Lefkowitz

Posts: 12
Nickname: glyph
Registered: Nov, 2003

Re: In search of a Pythonic, XML-based Templating Language

Posted: Nov 30, 2004 7:39 AM

Reply

You didn't mention Nevow ( http://www.divmod.org/Home/Projects/Nevow/index.html ) - is this in the same category that you're talking about?

Ryan Tomayko

Posts: 408
Nickname: rtomayko
Registered: Nov, 2004

Re: In search of a Pythonic, XML-based Templating Language

Posted: Nov 30, 2004 10:19 AM

Reply

> You didn't mention Nevow (
> http://www.divmod.org/Home/Projects/Nevow/index.html ) -
> is this in the same category that you're talking about?

Yes, I believe it could be considered in this bunch. I thought the following provided a bit more info on the framework:

http://nevow.com/Nevow2004Tutorial.html

Nevow looks like it is tied pretty closely to twisted, however. I'm more interested in standalone template languages that can be adapted for different needs (web templating, static file generation, transformation, etc.). I wonder how hard it would be to use just the templating piece without the rest of the MVC framework or twisted.

has

Posts: 15
Nickname: has
Registered: Nov, 2004

Re: In search of a Pythonic, XML-based Templating Language

Posted: Nov 30, 2004 1:36 PM

Reply

> Yes, I believe [Nevow] could be considered in this bunch.

Nevow's not a templating language but a collection of templating-related technologies that includes Nevow.Renderer, which compiles an HTML/XML template into an object model that can be manipulated programmatically, and Nevow.Stan, a programmatic HMTL/XML generator, along with a form builder and other cool-looking stuff. The main problem with Nevow's design, IMO, is dependencies: there's about half a dozen really interesting but very different technologies, each of which could/should really should stand on its own but instead they're all bundled up and coupled together. Not sure if it's still dependent on twisted, but if it is then I'd consider that a deal-killer too.

> I'm more interested in standalone template
> languages that can be adapted for different needs (web
> templating, static file generation, transformation, etc.).
> I wonder how hard it would be to use just the templating
> piece without the rest of the MVC framework or twisted.

I remember looking at it some time back as I'd an interest in playing around with Stan, but found it easier just to whip up a quick Stan clone than figure out how to decouple the original Stan. The situation may have improved (or maybe gotten worse) since then; I dunno.

As an alternative to Nevow.Renderer, you might try looking at my own HTMLTemplate module which uses the same simplified-DOM-style approach. (There's a couple simple examples included, and a nice meaty real-world example can be found in the htmldoc module of the appscript package also on my site.) HTMLTemplate doesn't XML templating straight out of the box, but that's mainly a limitation of Python's HTMLParser which could be replaced easily enough with another, XML-savvy, SAX parser. It's deliberately designed to be small, simple and easy to hack - e.g. I've created a improved version (unreleased; bug me if you want a copy) with a more uniform, flexible design and basic introspection support that'd allow one to implement neat stuff like automatic dict interpolation as add-on layers - so creating a powerful and flexible XML templating system out of it oughtn't to be too hard.

FWIW, I've designed and written both embedded mini-language and DOM-like templating systems, and while the former do have their niche the latter are far, far easier to implement, less rigid and constraining and much more elegant and easy to use, better suited to the majority of uses and users, and won't get you into trouble over Greenspun's Tenth Rule. If you're designing a templating engine from scratch, I really recommend you explore this approach before sinking lots of time into creating your own custom language from scratch when you could quickly and easily leverage the full Python language directly (a lesson I learned the hard way, ugh...).

HTH

Ryan Tomayko

Posts: 408
Nickname: rtomayko
Registered: Nov, 2004

Re: In search of a Pythonic, XML-based Templating Language

Posted: Nov 30, 2004 2:03 PM

Reply

> The main
> problem with Nevow's design, IMO, is dependencies: there's
> about half a dozen really interesting but very different
> technologies, each of which could/should really should
> stand on its own

Yep, that was my take as well.

> As an alternative to Nevow.Renderer, you might try looking
> at my own HTMLTemplate module
>

404? I'd love to check it out.

> ... get you into trouble
> over Greenspun's Tenth Rule. If you're designing a
> templating engine from scratch, I really recommend
> you explore this approach before sinking lots of time into
> creating your own custom language from scratch when you
> could quickly and easily leverage the full Python language
> directly (a lesson I learned the hard way, ugh...).

Exactly. Did you happen to peek at the language reference? One of my goals is not to write a new, crappy, Python just because I'm embedded in markup.

http://splice.sourceforge.net/kid/kid-spec.html

The XML templates are actually being compiled down to python byte-code.

Also, TALES ran into Greenspun's Tenth Rule if you ask me. It looks like there's two or three layers of apparatus on top of the basic concept and I can't see it getting smaller. Why create a new language when python works so well?

Thanks,
Ryan

has

Posts: 15
Nickname: has
Registered: Nov, 2004

Re: In search of a Pythonic, XML-based Templating Language

Posted: Nov 30, 2004 3:55 PM

Reply

>> As an alternative to Nevow.Renderer, you might try looking
>> at my own HTMLTemplate module
>>
>
>404? I'd love to check it out.

Tsk. Seems to be a bug in this forum's linkifying code that's messing up the href on the clickable link. Here, try again:

http://freespace.virgin.net/hamish.sanderson/

>> ... get you into trouble
>> over Greenspun's Tenth Rule. If you're designing a
>> templating engine from scratch, I really recommend
>> you explore this approach before sinking lots of time into
>> creating your own custom language from scratch when you
>> could quickly and easily leverage the full Python language
>> directly (a lesson I learned the hard way, ugh...).
>
>Exactly. Did you happen to peek at the language reference? One of my goals is not to write a new, crappy, Python just because I'm embedded in markup.

Yep. You're still defining a custom layer in your kid:... flow control structures though, rather than just using Python's own (as Nevow and HTMLTemplate do). The more responsibility you can throw onto Python the less you have to take on yourself - which means less work for you and less imposition on the end-user.

>Also, TALES ran into Greenspun's Tenth Rule if you ask me. It looks like there's two or three layers of apparatus on top of the basic concept and I can't see it getting smaller. Why create a new language when python works so well?

Exactly. With a lot of systems, adding new features means getting down and dirty hacking them into the core engine - a neverending process - rather than building a new layer on top of the current system that hooks in via an API. Having been there a couple times myself, I took some cues from Unix and Lisp philosophy and instead of designing in features designed them out, making them somebody else's problem. The only thing HTMLTemplate does is accept HTML and return simple Python-based object models, so it's much less feature-rich than most systems - but that's entirely by design. Because it's just a regular Python module using regular Python code it should be dirt easy to extend it with, say, mechanisms for caching, automatically loading and compiling file-based templates, etc. without clogging up the core engine - plus you can design those extension modules to be generic and reusable as well. A loose collection of independent modules might not have quite the same glamour as a big integrated framework, but it should grow more naturally and prove much more practical in use.

Beyond that, the next step would be to come up with a design that can be elegantly and indefinitely extended by users who need deep, highly specialised features like interpolation and transformations without clogging the system up for everyone else that doesn't need them. The current HTMLTemplate API falls somewhat short of ideal in terms of extensibility; to be honest, this wasn't a big consideration for me at the time - I was just happy at getting all my previous problems solved without looking for new ones to tackle. The tweaked version is a bit better, though there's doubtless still plenty room for improvement. Perhaps I should package it up and sling it into the wild where somebody else will maybe pick it up and run with it awhile. Still, it should make a pretty decent foundation for exploring and developing this aspect further. Once you've had a chance to check out the release version, drop me a mail if you're interested in exploring it further.

Cheers,

has

Jonathan LaCour

Posts: 6
Nickname: jlacour
Registered: Dec, 2004

Re: In search of a Pythonic, XML-based Templating Language

Posted: Dec 1, 2004 11:36 AM

Reply

Ryan,

Great work. I took a cursory glance at KID and played around with it for a while, and I like its simplicity and elegance quite a bit. Really, a good start.

A few things that I would like, or don't understand:

1. Do the templates *have* to be compiled? I prefer a
more jsp/aspx type approach where the templates are
compiled once they are hit, and then cached. This
makes it a lot easier during development to make a
change to a page without having a build anything
again.

2. I like how content can be pulled into elements using
kid:content attributes, but it seems odd that the
variables that the content are pulled in from are
at a module level. Doesn't this present a threading
issue? How about a ASP.NET-style "codebehind" object
that contains these variables? Does this make sense?

3. The interpolation of values in attributes is really
cool... why only in attributes? Thats very limiting
and only allows me to use this feature in attributes,
where I am least likely to need it?

I have other comments, but they can wait. These are the biggest things on my plate right now. I am very interested in building a nice pythonic web application toolkit, and KID would be a great place to start. I am very unsatisfied with all other offerings (PHP, Java/JSP/Struts/etc, ASP.NET, etc) except for Ruby on Rails (http://rubyonrails.org), but would like something similar in Python instead of Ruby.

Again, great work thus far.

Ryan Tomayko

Posts: 408
Nickname: rtomayko
Registered: Nov, 2004

Re: In search of a Pythonic, XML-based Templating Language

Posted: Dec 1, 2004 12:23 PM

Reply

> Great work. I took a cursory glance at KID and played
> around with it for a while, and I like its simplicity and
> elegance quite a bit. Really, a good start.

well shucks..

> A few things that I would like, or don't understand:

> 1. Do the templates *have* to be compiled?

No. Actually, I worked out a simple (cgi based) apache handler that compiles the first time as you mentioned. I've also added a kid command that executes templates directly. Lastly, you can put .kid files anywhere on your sys.path just like .py files and import them without having to compile first by calling the following near the beginning of your program:

import kid ; kid.enable_import()

From that point on, you can import kid files just like py files and things are compiled automatically, etc.

> 2. I like how content can be pulled into elements
> using kid:content attributes, but it seems odd that the
> variables that the content are pulled in from are
> at a module level.

They're not required to be. You can embed processing instructions anywhere inside the root element for local variables. Think of everything inside the root element as being within a function and everything outside of the document element as being module-level.

I will make sure I illustrate this better in the language reference. The examples all seem to be using the kid PI only at the module level.

All of this might change of course. I'm not perfectly satisfied with the current approach.

> How about a ASP.NET-style "codebehind"
> object that contains these variables? Does this make
> sense?

Yep. And I am a firm believer in separating object model / business logic from the presentation/data format. I envisioned the kid PI being used mainly to bring in any imports and maybe define a few presentation-level functions or classes. Not for business logic or application code. Those should be imported or passed into the template (which you can't do yet, btw).

> 3. The interpolation of values in attributes is really
> cool... why only in attributes? Thats very limiting and
> only allows me to use this feature in
> attributes, where I am least likely to need it?

I'll have to think about that. The reason I went with interpolation on attributes is due to hatred toward TAL's tal:attributes method of setting/adding attributes. I always liked the way XSLT allowed {} style attribute interpolation and wanted to bring it into TAL. I had never considered it for content.

One of the nice things about using kid:content instead of {} in content is that you can build templates that look somewhat correct to designers by adding fake content. This lets the designer get a better feel for what the template will look like when it is rendered dynamically. So there's some benefit to using a kid:content like model as opposed to interpolating expression in content.

On the other hand, it would make the templates quite a bit easier to read when you didn't have to worry about a designer.

Like I said, I'll consider this some more. At the very least, I wouldn't have a problem with turning that off by default but allowing templates to turn it on with something like the following:

> I have other comments, but they can wait. These are the
> biggest things on my plate right now. I am very
> interested in building a nice pythonic web application
> toolkit, and KID would be a great place to start. I am
> very unsatisfied with all other offerings (PHP,
> Java/JSP/Struts/etc, ASP.NET, etc) except for Ruby on
> Rails (http://rubyonrails.org), but would like something
> similar in Python instead of Ruby.

You might also want to take a look at SimpleTAL (or another TAL clone) in the meantime. I think you will like what you see. At this point Kid is very much just a simplification of TAL although I hope to grow it in a few directions that will distinguish it further. Not only that but I don't see Kid hitting 1.0 for at least another 2-3 months, possibly longer depending on how much I decide to take on. The basic concept that is there today could be stabilized fairly quickly but I need to add some form of templating/inclusions/filtering and that's where things will get a bit more complex.

Ryan

Jonathan LaCour

Posts: 6
Nickname: jlacour
Registered: Dec, 2004

Re: In search of a Pythonic, XML-based Templating Language

Posted: Dec 1, 2004 3:03 PM

Reply

> I worked out a simple (cgi based) apache
> handler that compiles the first time as you mentioned.
> I've also added a kid command that executes templates
> directly. Lastly, you can put .kid files anywhere on your
> sys.path just like .py files and import them without
> having to compile first by calling the following near the
> beginning of your program:
>
> import kid ; kid.enable_import()
>
> From that point on, you can import kid files just like py
> files and things are compiled automatically, etc.

Cool. It seems like you have thought this out pretty well. Are you planning on building anything on top of KID at a higher level than an Apache CGI handler to facilitate this? Possibly a mod_python method of doing this? That would seem like a logical step once the templating itself is completed.

> They're not required to be. You can embed
> processing instructions anywhere
> inside the root element for local variables. Think of
> everything inside the root element as being within a
> function and everything outside of the document element as
> being module-level.

I see what you are saying, and now I have looked at the actual compiled templates, and its clear that there is the opportunity for creating local variables in addition to the model-level variables.

I would honestly prefer the kid compiler to generate classes that can be instantiated with some sort of state data to facilitate session-specific data and fetching, as opposed to generating modules and functions. Just a thought.

> I will make sure I illustrate this better in the language
> reference. The examples all seem to be using the kid PI
> only at the module level.

This would definitely help me understand the intended usage pattern.

> > How about a ASP.NET-style "codebehind"
> > object that contains these variables? Does this make
> > sense?
>
> Yep. And I am a firm believer in separating object model /
> business logic from the presentation/data format. I
> envisioned the kid PI being used mainly to bring in any
> imports and maybe define a few presentation-level
> functions or classes. Not for business logic or
> application code. Those should be imported or passed into
> the template (which you can't do yet, btw).

I kind of like the model that ASPX uses, though I am not a big fan of ASP.NET itself. They have the approach that the template file contains markup and has the extension .aspx and the codebehind file, containing a class, has the extension .aspx.cs. I would like it if I could write:

template.kid
template.py

Where the kid file was always automatically compiled, and the python file contained the logic and data binding for kid:content references, etc.

> I'll have to think about that. The reason I went with
> interpolation on attributes is due to hatred toward TAL's
> tal:attributes method of setting/adding attributes. I
> always liked the way XSLT allowed {} style attribute
> interpolation and wanted to bring it into TAL. I had never
> considered it for content.
>
> One of the nice things about using kid:content instead of
> {} in content is that you can build templates that look
> somewhat correct to designers by adding fake content. This
> lets the designer get a better feel for what the template
> will look like when it is rendered dynamically. So there's
> some benefit to using a kid:content like model as opposed
> to interpolating expression in content.

Well, I see your point, but I think that kid:content would become unreadable if you needed to do some more complicated content generation. I think its probably workable though.

> On the other hand, it would make the templates quite a bit
> easier to read when you didn't have to worry about a
> designer.
>
> Like I said, I'll consider this some more. At the very
> least, I wouldn't have a problem with turning that off by
> default but allowing templates to turn it on with
> something like the following:
>
>


>   
>

Yeah, to me, readable templates are everything. I think that I would even sacrifice some architectural simplicity for more readable templates. That may just be me.

> You might also want to take a look at SimpleTAL (or
> another TAL clone) in the meantime. I think you will like
> what you see. At this point Kid is very much just a
> simplification of TAL although I hope to grow it in a few
> directions that will distinguish it further. Not only that
> but I don't see Kid hitting 1.0 for at least another 2-3
> months, possibly longer depending on how much I decide to
> take on. The basic concept that is there today could be
> stabilized fairly quickly but I need to add some form of
> templating/inclusions/filtering and that's where things
> will get a bit more complex.

I will definitely take a look around at what is available. I don't really have any pressing needs though, and I am mostly interested in the topic for personal use. So, I am more likely to watch something like KID progress for a while :)

Again, great work thus far.

Christoph Zwerschke

Posts: 1
Nickname: cito
Registered: Jan, 2005

Re: In search of a Pythonic, XML-based Templating Language

Posted: Jan 3, 2005 10:57 AM

Reply

Ryan, your project sounds very interesting. Like you, I have also checked several templating languages until I ended up with SimpleTAL. And I completely agree with you that TAL should not be the end of the road, because it is too artificial and adds too many new concepts and scopes to Python that are not really necessary, most strikingly the METAL extension where you really feel that this is too much complexity for too little effect.

The great mathematician Leonhard Euler dictated his most famous book "Anleitung zur Algebra" to a man who was a former tailor, and he changed the text until he had made sure that even that man understood what he wanted to write. I think a templating language should be very simple and intuitive, with other words: KISS - keep it simple, stupid: http://www.digital-web.com/articles/keep_it_simple_stupid/ (the short article is about web design but most of it also applies to creating a template language).

We should really try to understand which elements make the existing templating languages so attractive to use or powerful, keep these elements and concepts, and throw away the rest.

I suggest that you also have a look at XIST (http://www.livinglogic.de/Python/xist/) which is not exactly a templating language, but comprizes some very attractive ideas and concepts for generating HTML with Python.

Another aspect that should be considered in the development of Kid from the very beginning is internationalization. Kid should support creating multilingual web sites.

See also recent discussion on the SimpleTal mailing list:
http://owlfish.com/pipermail/simpletal-list_owlfish.com/2004-December/000055.html

Flat View: This topic has 9 replies on 1 page

Previous Topic

Next Topic

Sponsored Links

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use