I really can't show it off right now because I'm in the middle of rewriting it, having just separated it from the ORM I wrote at the same time.

..but I can describe it. And I might as well name it: "Cation". Pronounce in two or three syllables as you see fit.

The actual templating is bare bones: slurp in a template and substitute in a dictionary (aka hashmap). That's all encapsulated in a nice base class, an "Assembly", which makes that easier, but that's the basic methodology. No flow control (or any code) inside templates, just static text. If you want to repeat table rows, for example, that doesn't go in the template; it goes in the handler script. The template would just write:

<table>\n    %(TableRows)s\n</table>

The templating is really the weakest part at the moment, and I may rewrite it on a whim sometime soon. But Cation is a larger app framework. I always like to describe frameworks primarily by pointing out those places where you can easily flex them. So here are the biggies:

0. Not exclusively for web apps. The core Application framework is delivery-method agnostic. But the web app interface is the only well-developed one at this point. The Assembly class is ML-agnostic; I've used it for email bodies as well as HTML, for example.

1. Web server: Comes with an adapter for IIS/ASP, another for Apache/mod_python. Working on a third for WSGI (an emerging Python web standard). These are all 100 lines or less; new ones would be a snap for Twisted, bare CGI, Roxen, AOL, etc. If WSGI takes off, I won't have to care. ;)

2. Handles async servers which expect a callable iterator (instead of write() calls).

3. File-based vs. in-code templates: up to the developer.

4. Data Persistence: not included so grab someone else's (preferably my ORM ;)

5. Use the builtin URI-to-script mapper or roll your own (usually just means a modified regex). Or, bypass the mapper and call _dispatch directly (error page redirection does this, for example).

6. Page caching: up to the developer. Most Cation apps have a persistent module or two--if you want caching, stick a reference to the right Assembly in there.


Other things it does/is/has:

1. Logging
2. Top-level error trapping, logging, and pretty printing
3. Timed, threaded Worker classes for getting things done on a schedule, possibly recurring.
4. Handles central application configs, either from code or INI-style files.
5. Security is minimal. Only keeps a list of superusers at the moment, which is crucial for...
6. Admin web page, from which you can reload modules, get user last login times, see template constants, start/stop/modify workers.
7. Registry of startup/shutdown functions.
8. UI's (active requests) are centrally registered and managed.
9. Data type coercion (both inbound and outbound).
10. Admins can capture profile data per user per request.
11. HTTP uploads.
12. Standard subclasses of Assembly for common html elements: option, input type=checkbox, table, frameset, whole redirect pages.

What it doesn't do:
1. Sessions. Can't get the bloody things to work with ASP and I don't currently need them anyway.
2. No defined interface for remapping scripts. TODO.
3. Lots of things I can't think of right now.