Butts kicked, names taken

By Serdar Yegulalp | 2016/07/09 08:00


To drive the feature development and debugging of MeTal as vigorously as possible, I've been preparing to port all of my own blogs to it. Some of them, like Ganriki.org, provide a rich proving ground for both expanding MeTal's functionality and making sure its existing feature set is up to snuff.

This past week, I added a major new feature that helped build out Ganriki all the more: the ability to turn the contents of any template in a MeTal theme into an importable code module, so there's less comingling of code and templating. (It's also possible this will allow for ways to better segment off code that doesn't need to be touched by all and sundry, as per my previous post.)

Originally, the templating system used for MeTal allowed you to have blocks of code within a template -- essentially, inline Python code. Not bad, but the syntax of said code wasn't quite like real Python code, and so it made dropping in existing code tedious.

After some dinking around, I decided the smart thing to do would be to allow code to be saved into a template (one that never publishes, for obvious reasons), and to allow that template to be imported as if it were a module.

Let's say we have a template named Code (original, I know), with the following text:

my_thing = 1

To use this in another template, we simply say:

% module = load('Code')

(The prefacing % is how code is formatted when it's intermingled in templates.)

We can then invoke everything declared in the Code template as properties in module.

{{module.my_thing}}

yields 1.

Eventually I plan to build some protections around this mechanism. There's already a degree of security around it -- it isn't possible to invoke it anywhere but templates, you can't import code from any template set except the one assigned to that specific blog, and that code can't be accessed by lay users. But over time I imagine various exotic scenarios will emerge that demand better security, so I'll try to think about those ahead of time.

Part of why I wanted to create this whole mechanism in the first place was to have centralized places in templates to place routines common to blogs. For instance, I have custom routines to add copyright information to images, which run whenever a template is published. Having them in a module I can import like regular Python code drastically simplifies the site development process.


Tags: features progress templates


comments powered by Disqus