Zylla is my cute little Python web framework and part-time giant lizard. It’s currently in heavy development, and I’m more than happy with the results so far. The latest feature addition, in my humble yeah-I-wrote-it-myself-I-have-to-really-dig-it-so-sue-me opinion, made it even cooler.

Up to now, Zylla web methods were expected to return strings that would be sent to the client (after running it through filters registered with the web object), which allowed you to render your output straight from within what ideally should be your business code. The best you could do to move the presentation logic outside was feeding your business results to template objects and returning their output, but all from within your supposed business code. This usually didn’t mean a lot of work and allowed you to quickly whip up your own mostly-MVC style code, but it did have the large disadvantage of making unit-testing Zylla classes harder than necessary.

While not really part of the original plans, Zylla now has a built-in view layer mechanism which is to be considered experimental at this point, meaning that it can and probably will change a couple of times before the first public Zylla release. (It’s in the repository, though, if you want to play around with it.)

Essentially, Zylla still allows your web methods to return strings and will happily forward those to the client, but your methods can now also return dictionaries of return values instead, which will then make Zylla feed these values to a (Cheetah) template designated by the handler class and method names.

Here’s a Zylla class taken from a current toy project:

class Home(Page):
    def index(self):
        ''' Display a list of the 10 latest questions. '''
        return {'page_title': 'Latest questions',
                'latest_questions': data.Question.get_latest(10)}

    index = zylla.expose(index)

The returned dictionary is automagically passed (by Zylla) to a template called ./templates/home/index.tmpl:

#if $latest_questions:
    $_z_iterate_template('question', $latest_questions)
#end if

_z_iterate_template iterates through $latest_questions (which is the variable the template received from the web method) and passes each item to another template, ./templates/question.tmpl:

<a href="/question/view/$question.id">$question.title</a>
(in $_z_template('taglinks', {'question': $question}))
<br/>

Things I like:

• Your business code doesn’t have to worry about the actual output any longer. It can focus on moving data around or whatever your application does, and you don’t have to couple your application with a specific templating layer.
• Using different view layers, you will be able to use the same business code to display completely rendered HTML pages, but also serve data via XML-RPC and such.
• It’s a lot easier to test your business code, since you can now work with the result actual data contained in the returned dictionaries.
• Most importantly, IMO: less code, faster results. :)

Things I’m not too happy with at the moment:

• Zylla’s web methods are very “pythonic” because they accept GET/POST parameters as standard Python method parameters. This is good. But returning dictionaries of values doesn’t really fit into that picture. Maybe I should allow web methods to return single values, too? Zylla could move this single value into a template variable called result and pass that to the view templates using the same mechanism as usual. This wouldn’t even conflict with still being able to return rendered strings. I guess if there’s an internal default view template like $result.__str__(), it would be wonderfully consistent, too. :)
• I don’t like how the code posted above includes page_title in the results dictionary. Since the business code shouldn’t be concerned with the view layer, why would it return page_title? To be honest, this is a quick workaround I’m currently using because the little toy application this code is from uses an “outer” template to wrap a nice HTML design around the method templates, and I haven’t figured out a clever way of passing variables defined within an “inner” template to the other. This is a big todo right now.
• I’m not perfectly happy with how all this view layer stuff is built into Zylla’s core code. I believe it should really be an aspect that you apply to your web classes. Not that I’m counting on anyone not wanting to use this new mechanism, but if it is contained in an aspect class, you’ll get all the additional benefits of aspects: being able to use different view mechanisms in different parts of your site, subclassing the aspect class, and so on… ah, wonderful.
• Template files are currently arranged in a fashion that may not be entirely compatible with how your Zylla classes are set up. Specifically, if you have two Zylla classes with the same name, but contained in different packages/modules, there will be a naming conflict for the templates. So I’ll have to figure out a way of allowing Zylla classes to configure their template directory. Or something.

And if you believe “part-time giant lizard” sounded kinda wrong, I think I agree!