Kid Template Extension
Source : Lion Kimbro's Blog
I’m working on the My Local Names website; It’s going great. I used yesterday to layout the front page.
I wrote the HTML page using Nvu. Two great things about Nvu: you don’t need to memorize CSS terms, and you can change CSS in the GUI editor, and see the effects in real time. When you delete the “2″ in “20,” on the margin-top, en route to replacing it with a “3″ for “30,” you see the actual content jump around, as it happens. God I love Nvu. No, it doesn’t make you an idiot; You learn the CSS terms as you use it. Nvu is a great editing and learning tool.
I made a small mistake, misuing Nvu a little bit- I made the mistake of telling Nvu to work the style sheet into the page itself. That meant that, to integrate it with TurboGears, I had to extract the CSS.
I want to put the site online, on taoriver, but before I do that, I need to integrate the single HTML page from Sunday into my TurboGears project.
This entails working in the header, footer, and site CSS.
Now, where do you put the CSS? TurboGears has already made a space for this, in “mylocalnames/static/css/”. I decided to use the name “site.css.”
Now I need to change the master.kid file, which most template inherit from, so that all the pages get the site.css. But that meant: I had to learn some kid.
Kid is… …pretty clever. Kid, briefly, is the templating system used by TurboGears- When you’re rendering HTML, and telling the computer how to put variables into sections of HTML- this is what you’re using.
Kid is based entirely around XML. What that means is that it has a lot of special things for replacing and traversing and working with XML. Also, a lot of the commands integrate with XML. You can see this clearly by looking at the attribute reference.
I’m not sure whether I like Kid more than Cheetah or not. I think I like Cheetah more, because it’s a lot simpler: It’s a lot more “straight Python,” and less messing around with XML attributes. It felt much more comfortable, to me, as a Python developer. Cheetah has also been around for much longer, and also has a much more comprehensive and stable set of documentation. Cheetah’s a real no brainer, in my mind, and that’s a good thing.
In Kid’s defence, it’s quite elegant. The way it melds into XML is svelt, like the curve of a woman’s hip; Cheetah in contrast appears ham-fisted, like a square jawed thug. This is because Cheetah makes use of raw (blocked) Python, and Kid puts control structures into XML.
Unfortunately for Kid, I prefer the simple-minded square jawed thug, while programming, to the svelt but more complicated beautiful woman. The stereotypical woman is a complex creature, and many men work on computer programs to get away from that kind of complexity. This line of thought places me entirely in the land of Cheetah.
Crazy anthropomorphizations aside, this is not a stopping issue for me; It just means I have more stuff to learn. And in the end, it’s not a thug or a woman, but rather, simply, an XML templating system, that happens to be integrated into TurboGears. So Kid it is.
It took me a while to figure out the py:match py:extends system, which is crucial to using TurboGears effectively.
The single most important thing to me, was the insight that py:match only pulls in py:def and py:match instruction.
Now, why is that so important, and why was I confused about it? I mean, the py:extends says exactly that, right there in the documentation! A couple things.
First: master.kid has a bunch of content in it that has no bearing whatsoever on the child template. For example, it has a head block. But the entire head block is completely ignored, when the template is extended.
Why is it there, then? I guess so that you could, theoretically, open up master.kid in a web browser. But I find this “feature” more confusing than helpful: I never look at my templates in the web browser, and I was-led/led-myself into thinking that the content was actually substantial. It has no substance beyond decoration of the master template.
Second: I was misled by an erroneous wiki page! Someone had applied an edit. The edit was actually good- it produced a fuller response, and pointed out an intricacy. BUT: The user did not update the output, and that led me astray for a few hours.
In short, the output that the page says it produces, is not the output that the page actually produces. I was baffled and studied Kid a bunch, to understand how the output could be produced. But I finally realized: “Wait, the page must be wrong,” checked the page history, and discovered what had happened. Yep: the page was wrong.
I’ve added documentation to the page, explaining the substance of the
$item.text$item[:]content.I’m still figuring out how to correct the page- should it use py:replace, which gets rid of all the interior content, but misses the first
$item.text? Or should it use$item.text$item[:], but leave lingering “content will be inserted here (both elements and text):”..?By the time you read this, I’ll have probably corrected it one way or another.
Anyways. I learned a lot of Kid by going through all of this.
Suggestion for TurboGears: Provide the user, by default, with an empty (or basic) stylesheet? Call it “/static/css/site.css”, or something, and automatically pull it in through the master.kid /head. That way, you just stick your CSS in there, and it’s automatically in all pages that inherit from master.kid.
All in all, I’m having a great time, and can’t wait to show you the new my.localnames website!
The sooner I get that through, the sooner I can get to my WordPress plugin, and stop looking up the URLs all the time on the web, to paste them into little a href’s here!
Lion
le 01.01.06 à 23:16
dans News / Actualités
- 
Article précédent - Commenter - Article suivant -