Michael Kerrin

Web, Python, JavaScript and related technologies

Archive for the ‘python’ Category

pwt.jinja2js 0.6.0

with 2 comments

I have just uploaded a version 0.6.0 of pwt.jinja2js. This adds support for default values for macros arguments. So now you can do this:

{% macro defaultparam1(name = "World") -%}
Hello {{ name }}!
{%- endmacro %}


And you can call this like so to produce the desired output:

defaultparam1({}) -> "Hello World"
defaultparam({name: 'Michael'}) -> "Hello Michael"



Written by mkerrin

2011, April 5 at 10:33 am

pwt.recipe.closurebuilder 0.9.3

leave a comment »

Released new version of pwt.recipe.closurebuilder to PyPI. This just contains small updates to the closure libraries from Google.

Written by mkerrin

2011, April 4 at 10:30 am

pwt.jinja2js documentation

leave a comment »

The documentation for pwt.jinja2js has now been uploaded to PyPI. See them here.

Written by mkerrin

2011, April 4 at 9:45 am


leave a comment »

I have just released pwt.jinja2js This is my compiler for Jinja2 templates that compiles to Java Script. If anyone noticed I renamed the project from pwt.jscompiler that I previously announced on this blog. But pwt.jinja2js is now released to PyPI which should make it easier to use and fixes the name in stone now.

I started this project so that I could easily use templates in my Java Script code. Most other Java Script templates require web developers to include the template they want to render inside the HTML returned from the server. This is annoying as you have to remember to include both Java Script and your HTML snippet in the response, increasing the load of the HTML page resulting in slower website. I found and used Closure templates for a while. This does what pwt.jinja2js does and inspired me to work on this project. But closure templates is a Java project and the only way to use it in a Python project is via the command line which is annoying.

pwt.jinja2js works by compiling any macros found inside your Jinja2 template into a Java Script function that you can call just like any other Java Script function and it will return a rendered string of your template and data. It is then up to you to do what you want with this string. In order to know what function to call pwt.jinja2js uses the name of the macro as the name of the Java Script function but also includes a special namespace node that you can include in the top of the Jinja2 template so that all the Java Script functions are called after their macro name prefixed with the namespace supplied. So that you can avoid namespace conflicts.

pwt.jinja2js can be invoked numerous ways, the two main ways been on the command line by calling the jinja2js script which you get for free after running easy_install pw.jinja2js, which just writes the output of templates disc which can then be served along with all your other static files. The other way is to configure a WSGI server to run the pwt.jinja2.wsgi.Resource application. This will find all your templates in the same way as Jinja2 does and will render them on the fly and return them with the correct mine type so your browser will treat it as Java Script. For performance considerations you should compress your Java Script including the generated Java Script from your templates with a tool like Closure compiler, YUI Compressor, or any other similar tools. I personally use pwt.recipe.closurebuilder to integrate the closure compiler with my zc.buildout build to get the best result.


Written by mkerrin

2011, April 1 at 3:55 pm


with one comment

Following up on my pwt.recipe.closurebuilder announcement, I have pushed a new project to github called pwt.jscompiler. The goal of this project is to write a JavaScript compiler for Jinja2 template engine. My work builds on Jinja2 reusing as much as possible. The idea is to write templates that can be reused to a limited degree between your Python code running on the server and your JavaScript code running in the browser. There will be limits to what can be supported for now. This is a pre-alpha release. It needs a bit more work to be fully functional and with as few bugs as possible.

pwt.jscompiler will take a Jinja2 template with macros in it, and compile all the macros to JavaScript functions. I have added a namespace node to Jinja2 so that I can generate meaningful names on the macros and so that I can use Closure library namespace and dependency management features. Currently I don’t support not using closure library but this is a bug and will be fixed in the future.

Other features of the pwt.jscompiler is the ability to serve the templates via a WSGI application that compiles the template to JavaScript. This is handy for development where you can put <script> tags in your page pointing to the WSGI application and template name. It also supports integration with the pwt.recipe.closurebuilder. To use integration all you need to do is change the dependency recipe that finds and maps all your JavaScript dependencies from pwt.recipe.closurebuilder:dependency to pwt.jscompiler:dependency and include the directories of your Jinja2 templates like you would for any JavaScript dependencies. The integration will compile your templates to JavaScript into a temporary file and add this to your dependency tree getting compiled down along with the rest of your JavaScript dependencies.

Written by mkerrin

2011, March 3 at 3:11 pm


with one comment

Its been a while but I am going to be releasing some open source packages in the near future.

First up is pwt.recipe.closurebuilder. This is a zc.buildout recipe that integrates with closure-library build system. Then pwt.recipe.closurebuilder makes it easy to find and minify all your JavaScript files that make up your application into one or more files. Obviously if you don’t use zc.buildout that it is not going to be of much use, but the idea behind the closure JavaScript dependencies is worth reading about IMO.

pwt.recipe.closurebuilder contains two recipes. One to generate a JavaScript file containing a database of dependencies between all your JS files using closure library namespaces. This is equivalent to the depswriter tool from Google.

The second recipe invokes the closure compiler to produce a minimized version of your code base. It uses the information gathered through the first recipe to find a list of all the files that you want to collect and minify into one small JavaScript file. This file is saved in a output directory specified by you and whose name is the md5 sum of the contents of the generated JavaScript file. This recipe is equivalent to the closurebuilder tool from Google.

The closure compiler is the best JavaScript to JavaScript compiler out there that minimizes your code the most. But using it repeatable and consistently can be a problem. As I use zc.buildout whenever possible integrating the minimization of your JavaScript into my build system of choice makes life easier.

Written by mkerrin

2011, February 22 at 9:08 am

PyCon Ireland

leave a comment »

PyCon Ireland was held last weekend. It was a great success and I can’t wait for next years conference.

I present a talk on front end web performance and development. How it is difficult to create a consistent, fast user interface, without breaking the principle of Don’t Repeat Yourself which pretty much all frameworks try to adhere too. Two other talks, one presented just prior to mine and the second just after, by Arthor Cistov discussed the same issues but he had a lot better slides and went more in-depth into the JavaScript / HTML side of the discussion.

Here is my presentation on slideshare.net. Hopefully I can get motivated to blog about this topic in the future.

Written by mkerrin

2010, July 21 at 4:16 pm