Tir is an experimental web framework for the Mongrel2 webserver and Lua programming language. The purpose of Tir is to play with the idea of a State Agnostic web framework. Tir lets you create handlers that work in various configurations as needed by your application requirements. You create your application using a natural coroutine style handler, then make another part stateless, and still have other parts using an evented/callback style.
Tir is very alpha, but it is being used on a few projects. Feel free to grab the code and if you want to help, then contact zedshaw-AT-zedshaw.com for more information. The source to Tir is available at http://tir.mongrel2.org/downloads/tir-0.9-1.tar.gz.
Install instructions and more information can be found on the Tir website at http://tir.mongrel2.org
Tir's philosophy is that the framework creator shouldn't be shoving stateful/ stateless dogma in your face, and that it's possible to support various state management styles. Tir allows you to use different state management strategies for different interfaces you need to design.
- If a part of your application is a complex process, then Natural Style is the way to go.
- If there's a single URL service then Stateless Style is the easiest.
- If you have a URL+action for say a REST API then Evented Style works great.
The point though is that different problems are best solved with different state management.
I'm calling the coroutine based handlers "Natural Style" because you write the
code for them in a more natural way, as if you don't need to worry about
routing and state management. You can code up entire complex processes and
interactions using the natural style very easily. For example, pagination is
difficult in stateless servers, but it's just a repeat/until loop in natural
style.
By default, handlers are natural style and maintain a coroutine for each user
and let you write your code using phrases like prompt
, recv
, page
, and
send
.
local login_page = Tir.view("login.html")
local login_form = Tir.form { 'login_name', 'password'}
local function login(web, req)
local params = login_form:parse(req)
repeat
params = web:prompt(login_page {form=params, logged_in=false})
until login_form:valid(params)
return web:redirect('/')
end
Tir.start {route='/Login', main=login}
Handlers can be made "stateless" and they'll work like coroutine handlers, but not retain any state. These are good for one-shot operations and simpler actions that don't need much routing.
local search_page = Tir.view("search.html")
local search_form = Tir.form {"q"}
local function search(web, req)
local params = search_form:parse(req)
local q = params.q
local results = {}
if search_form:valid(params) then
local pattern = ".*" .. q:upper() .. ".*";
for i, cat in ipairs(categories) do
if cat:upper():match(pattern) then
results[#results + 1] = cat
end
end
end
web:page(search_page {results=results, q=q})
end
Tir.stateless {route='/Search', main=search}
Tir also supports the alternative "evented" style, which means that URLs are
mapped to callback functions in your handler. A simple URL pattern is used to
transform your /Route/action
style URLs into a function to call. Best of all,
evented operation can be combined with stateless (the default) or coroutines,
so you can easily refactor complex URL schemes if you need:
local Manage = {
form = Tir.form {"id", "action"}
}
function Manage.people(web, req, params)
-- Do whatever managing people does.
end
function Manage.cats(web, req, params)
-- Whatever managing cats means, if that's possible.
end
function Manage.dogs(web, req, params)
-- Ah way easier to manage dogs.
end
Manage.config = {
route='/Manage',
}
Tir.evented(Manage)
In this style, Manage.form
is run and then your handlers receive the results to
work with right away. You can even change the routing pattern if you don't like
what I've chosen, or need even more complexity in your life.
Tir uses embedded Lua as it's templating language, which means you get a real language and not some crippled one someone smarter than you thinks you should be using. And Lua already looks like most of the nice template languages out there:
{% if #results > 0 then %}
<ul>
{% for _,result in ipairs(results) do %}
<li>{{ result }}</li>
{% end %}
</ul>
{% else %}
<p>We'll add "{{ q }}" as a new one.</p>
{% end %}
Tir also uses ZeroMQ and Mongrel2 to run the application as a set of small
processes for each major routing, rather than one monolithic process. In the
above two examples, each Tir.start
line is a single process.
You can also build on this to flex and warp the size of your processes as you
need, and locate them or cluster them however you like. By default it shoots
for small little processes, but nothing prevents you from doing others.
Tir.Task
lets you create and connect to ready to run 0MQ background task
processes so you can offload long running tasks and avoid holding up web
requests. They're designed to be very easy to use, but still flexible enough to
let you do what you need. By default they use PUB/SUB sockets, but you can
change that with a setting. You can also put the background tasks on clusters
of machines and nearly anything else you need to do. Messages are simply just
JSON encoded Lua structures.
Here's a Task that just dumps it's args.
require 'tir/engine'
function test(args)
Tir.dump(args)
end
Tir.Task.start { main = test, spec = 'ipc://run/photos' }
And here's a sample Handler that can talk to it:
require 'tir/engine'
local conn = Tir.Task.connect { spec = 'ipc://run/photos' }
function main(web, req)
conn:send('photo', req.headers)
web:ok()
end
Tir.stateless {route='/Task', main=main}
New in 0.9, Tir now has decent unit testing in the tir/testing library and there's a sample test in the Getting Started guide that shows how it's done.
Because Tir uses Mongrel2 it already support async operation, streaming, regular HTTP, HTTP long poll, and flash/jssockets.
Tir comes without an ORM by default. People would probably hate any ORM I wrote and there's plenty of options you can add.
This isn't really a Tir feature, but don't you hate it when there's bugs in your core libraries and that guy who "owns" the broken library refuses to fix it? Me too, that's why Lua and LuaRocks are awesome. You get a tight core language that's completely described in a few HTML pages, and can install all the platform libraries you need with LuaRocks. No more gatekeepers with Lua.