Keith Devens .com

Yes, Cheetah IS nice. The one thing I've found is that debugging a template can be hell if your data doesn't match the "placeholders" in the code, or if you have objects with similarly named attributes and it's not matching.

I've been working with RSS data where I have a channel object with title and link atributes. I'm also dealing with a #for loop in my template over a group of RSS item*s which each have a *title and link.

So, when it tunred out that my $placeholder was missing a component, all Cheetah said was something like "NameMapper error: 'title' not found". And I had no idea which part of the template was horking. Maybe there are some debugging fdeatures of CHeetah that I've missed, but I'd like to get the whole placeholder value in that error msg: "'story.title' not found", or "$obj.title" not found."

In this case, I was missing a component of the placeholder (the item was actually nested one more level, so it had to be $obj.item.title) but the error msg was not helping me figure that out. I ended up rewriting a bunch of code to make every attribute on every object have a unique name so that when it blew up I could figure out where it was happening. Argh.

Ok, I really wish I could edit comments b/c I made some naaasty typos in that last one.

The one thing I've found is that debugging a template can be hell if your data doesn't match the "placeholders" in the code, or if you have objects with similarly named attributes and it's not matching.

Cheetah is a little unforgiving when it doesn't find a placeholder - it just raises an exception and tells you which variable wasn't found (keep in mind though that this is almost certainly the most appropriate default behavior). This is easy to take care of in a whole bunch of ways. I happen to have made a custom searchList object that can respond to any placeholder request. So, for instance, I can just return an empty string, or something like "$foo NOT FOUND", when a variable that doesn't exist is requested, which will show up right in the template where $foo was so it'll be real easy to see what the problem is. There are also more "conventional" ways to handle this that I explain below. Keep in mind that I needed this "custom searchList object" for another reason... I wouldn't have made it just to provide "not found" errors.

Cheetah, of course, has a whole bunch of intelligent ways to debug a template that don't require the hack I explained above. Check out section 5.7 and section 10.2 in the documentation. And as a last measure, it's really easy to get the compiled template source dynamically and use the stack trace to find out exactly which line failed, and Cheetah also does an amazing job of making the relation between the compiled template and the original template source very clear. There's no reason to go through all the trouble you say you went through.

Arguably, Cheetah should be a little more clear about reporting that $bar.foo could not be found rather than just foo. But, since the lookups are probably done recursively, there's probably no easy way for them to provide that information that's worth the trouble (especially given all the other ways there are to handle these types of errors). Though there may be, and I'll try to look into it. The code is so good I'm sure it'll be a piece of cake to fix if I want to.