Kid 0.2 and a note on Template Design

I pushed up a much needed 0.2 release of Kid today. I hadn’t meant for my previous post to be an announcement but I got quite a few comments showing interest and was surprised to see some people actually grabbing the 0.1.1 release. As it was, for all intents and purposes, not a release at all. The 0.2 release should be somewhat more stable. At least enough to dive in and play around.

I usually don’t enjoy documentation but for the most part, the doc has been writing itself on this project. I think the key is making sure you are concentrating on something small enough that you can see the end of the documentation.

When you’re documenting a year’s worth of coding - you’ve lost. It just isn’t going happen.

One of the topics that has come up in comments and email is the ability to embed blocks of Python code in the XML template, much like you would with PHP, JSP, ASP, etc. but actually not like those at all because it’s not useful for controlling output, only for priming the context for template execution.

But code in templates is generally considered bad form as it can lead to a mash of concerns. I agree with this as a best practice and subscribe to something pretty close to a standard MVC design pattern myself. However, my experience with TAL, which allows only Python expressions, and those only in controlled circumstances when you have no other choice, was that I often wanted to just drop a couple of quick formatting-specific functions somewhere. Instead of putting them in the template, I was forced to pile them into a cruft module that just pissed me off every time I had to use it.

One of the reasons I’m so attracted to Python is that there’s very little “saving people from themselves.” Whether it be the liberal take on private attributes in classes, the ability to modify an objects member __dict__, the disregard for interface as contract, or a myriad of other aspects of the language, Python’s utter disrespect for all things sacred and holy in protecting machines from the idiot programmers that abuse them really flipped a switch for me.

I’ve grown to expect this from my tools and libraries. The “force them to be good and proper programmers” attitude around Java programming has become a drag.

But I still program like that in Java because it makes sense in Java, which is even more puzzling. One might assume that upon appreciating the ability to get at pseudo-private members in Python that the practice would transfer to other languages. My Java classes instance variables should be at the very most protected, right? It doesn’t work that way. The concepts aren’t portable between languages.

This goes for other aspects of the language as well. Unchecked Exception’s immediately come to mind as something I value tremendously but cannot, even though technical feasible, bring myself to advocate seriously on the Java side.

I’m rambling now so I’m going to end this with a bit I finished up on tonight from the Kid Tutorial, where an attempt is made to convince the programmer that there is rarely, if ever, a situation where making blanket rules about what types of ways you might allow yourself to manipulate a machine is in your best interest. You can always refrain from doing something you’re able to do, but you can never do something you’re not able to. That’s not to say a system should not have constraints, just that it should not be constrained needlessly.

And of course, the following references to the Worse is Better mindfck is attributed to the masterful Richard Gabriel (or whatever his real name is).

A Note on Template Design

It is possible to embed blocks of Python code using the <?kid?> processing instruction. However, the practice of embedding object model, data persistence, and business logic code in templates is highly discouraged. In most cases, these types of functionality should be moved into external Python modules and imported into the template.

Worse is often not better.

Keeping large amounts of code out of templates is important for a few reasons:

Clearly, worse is not better.

That being said, circumstances requiring somewhat complex formatting or presentation logic arise often enough to incline us to include the ability to embed blocks of real code in Templates. Template languages that help by hindering one’s ability to write a few lines of code when needed lead to even greater convolution and general distress.

Worse is sometimes better.

That being said, there are some limitations to what types of usage the <?kid?> PI may be put to. Specifically, you cannot generate output within a code block (without feeling dirty), and all nested blocks end with the PI.

You cannot do stuff like this:

<table>
  <?kid #
  for row in rows: ?>
    <tr><td kid:content="row.colums[0]">...</td></tr>
</table>
<p><?kid print 'some text and <markup/> too'?></p>

This is a feature.

Worse is sometimes better but oft is just worse.

Not exactly sure what I’m trying to say with that whole deal but I think that’s the point. You need to be able to make decisions when you need to make decisions.

Thanks for listening!