A couple of years ago we developed a project management system for use internally. The app itself is quite complicated as it manges the entire application lifecycle and allows customers to interact in the development process. Problem is, the database is well normalised and the structure is PROJECT > PHASE > FEATURE > TASK (with a raft of other tables to boot). So when we're looking at the task, the projectid is lost (not relevant at this depth) but is required in order to determine security (eg who has access to what project).
To date we solved the problem by storing the current project id on the user's session object on the server. Unfortunately this means you can only really access one project at a time. Of course this breaks if you are "in" one project and click an email link to another. It's actually quite difficult (and clunky) to pass around the project id in all urls (/group/app.pma/page?openpage&projectid=999). It would be great if we could set the project once and not have to worry about passing it around. So I thought about using the group portion of the url to store the project id.
Sooooo. Tornado now supports wildcard applications. When you set up an app, you can specify the group as '*' which means the uri will match on ANY group value you specify. The app is now set up as '/*/app.pma' in the webdesigner. If a user tries to access '/BBB/app.pma' or '/AAA/app.pma' or '/123/app.pma' the same application will be served. As a programmer we can now access the group property of the request to determine the current project id.
I was expecting it to be huge pain, but it actually only took about 10 minutes. Problem solved :-) This is going to have some brilliant implications for hosted apps we're currently building. Watch this space!