Positron version 0.0.7 released

2013-12-11

The next version of Positron, version 0.0.7, has been released on CPAN. This is the first version to have a codename, for obvious reasons. I call it "Codename: 'Meta-Codename'". (There was a 0.0.6, too, for one day. The next one was going to be 0.1.0, since it wraps up the DataTemplate part. But one does not simply pass up a 0.0.7 .)

Not much to say, this version is the one with my very own expression parser. This should not be externally visible, however, except for the smaller list of dependencies.

What is more visible is the hardening of syntax and softening of semantics of expressions and environments:

Hardening

The expression parser will not give up half way through an expression if the first part is syntactically valid, and the second part isn't. So "this ? that :" will now complain instead of ignoring the ":" just because it's "seen enough". The complaint is in the form of an exception, and should carry enough information to find and correct the error. Remember: no matter what your data may turn out to be, a syntactically invalid expression is never a good thing.

Softening

On the other hand, once the expressions parse, they are quite lenient, maybe even surprisingly so. If your expression reads "entry.date.format_date("year")", but your environment doesn't even contain "entry", the expression will quietly evaluate to undef. There may be an option in the future to warn when this happens, but it's not a high priority.

Several other templating engines complain left and right. They complain when you use data without defining it, and (in some cases) when you define data but never use it. The purpose of this is to warn you of potential typos: if you define "referer" but attempt to access "referrer", the template had better mention this, or you could waste a lot of time trying to find out why this doesn't work.

In the real world (ok, ok, "in my day job"), however, we do things differently. The person providing the data and the person constructing the template are two separate people, working in different offices on different schedules. So data is typically provided before the template is even ready for it. And it's a lot easier to write-test-correct-repeat the template bit by bit, rather than to use all parameters somewhere just so that the templating engine will shut up and start showing anything.

Additionally, sometimes data is naturally overprovided. The data may be a dump of a database table, regardless of which columns may or may not need to be displayed. Why waste time pruning it? Requirements change, too. Today, each restaurant in the guide must display the number of reviews next to the title. Tomorrow, just the title. Imagine having to adjust the data model (by a different person, remember!) just to tweak the view.

Thirdly, templates may be used for multiple purposes, or be included in several other templates. A list of gadgets includes both a recommended retail price and a "street price" for each gadget. A list of announced or rumored gadgets has neither. It's still a list of gadgets, though, so why not share the same look?

And typos? The template crew has a full collapsible tree view of the data, automatically generated, next to the template's output. If an element is not showing up, or not working as expected, the first thing to check is the actual structure and contents of the data in question. Including the name, in a copy-and-paste-friendly format.