plonewars.com

I mentioned a templating language I put into Paste a while ago, but since then I extracted it into a separate package called Tempita. I think the documentation is fairly complete (it’s a small language), but I’ll describe it shortly here.

I wanted a text-substitution language, because I wanted something to be used to generate Python files, config files, etc. I also didn’t want a complex API, with search paths and components or something that interacts with import machinery, or any of that. string.Template is almost good enough, but not quite.

I started with the idea of something vaguely like Django Templates, though since I didn’t care about more advanced templating features like blocks that didn’t apply to my use cases. You do variable substitution with {{var|filter}}, and there’s no escape character, and that’s about where the similarity ends.

I realized there was no real reason to use anything but {{…}}, so it’s just {{if expr}}, {{endif}}, etc. There’s an escape for arbitrary Python, similar to how Kid does it — you can have blocks of Python code, but the Python code can only prepare variables and functions, it can’t write anything. I think this gives a nice escape for complex logic (for times when you can’t put the logic in a .py file), without the jumbled mish-mash of languages like PHP where you can trully mix functions and output.

Because it allows Python expressions everywhere, special tags don’t seem so necessary. Instead you can just provide functions to do whatever you need. I wrote a couple little ones as a start. There’s a few things that are awkward still, because there’s no way to define a block of template as a function, or pass the output of a block to a function. I haven’t actually needed these yet, but I can imagine needing this (e.g., when creating nested structures).

I wouldn’t suggest using this templating language in a web application, but I think it can be quite helpful for all the cases where you have to generate text and you aren’t writing a web application (e.g., a Framework Component). In my experience the web templating languages tend to be complex to invoke and understand in these contexts (and Buffet unfortunately doesn’t help in my mind, as it’s loading system is so vague).

One of the thinmgs I would like to do is to interact with Atompub (aka Atom Publishing Protocol) stores in Javascript through the browser. Since this effectively the browser itself interacting with the Atompub server, browser-like authentication methods would be nice. But services like Atompub don’t work nicely with the kinds of authentication methods that normal websites use. One of these is OpenID, which is particularly browser-focused.

From the perspective of a client, OpenID basically works like this:

• You need to login. You tell the original server what your OpenID URL is, somehow.
• The original server does some redirects, maybe some popups, etc.
• Your OpenID server (attached to your OpenID URL) authenticates you in some fashion, and then tells the original server.
• The original server probably sets a signed cookie so that in subsequent requests you stay logged in. You cannot do this little redirection dance for every request, since it’s actually quite intrusive.

So what happens when I have an XMLHttpRequest that needs to be authenticated? Neither the XMLHttpRequest nor Javascript generally can do the authentication. Only the browser can, with the user’s interaction.

One thought I have is a 401 Unauthorized response, with a header like:

WWW-Authenticate: Cookie location="http://original.server/login.html"

Which means I need to open up http://original.server/login.html and have the user log in, and the final result is that a cookie will be set. XMLHttpRequest sends cookies automatically I believe, so once the browser has the cookie then all the Javascript requests get the same cookie and hence authentication.

One problem, though, is that you have to wait around for a while for the login to succede, then continue on your way. A typical situation is that you have to return to the original page you were requesting, and people often do something like /login?redirect_to=original_url. In this case we might want something like /login?opener_call=reattempt_request, where when the login process is over we call window.opener.reattempt_request() in Javascript.

Maybe it would make sense for that location variable to be a URI Template, with some predefined variables, like opener, back, etc.

For general backward compatibility, would it be reasonable to send 307 Temporary Redirect plus WWW-Authenticate, and let XMLHttpRequests or other service clients sort it out, while normal browser requests do the normal login redirect?