Recently in Schematic Category

Schematronic is… my first python application, not initially destined for production use, instead a paythway for learning python.

It uses CherryPy and a lot of ideas from pycoon and nexista.

Schematronic is… is a work-in-progress experimental python-powered Nexista port.

What does that mean? Schematronic uses a sitemap (or what I like to call a fence file) to dispatch requests to resources, commonly things like data (SQL or XML) and views (XSL). It meshes up loosely with the Cocoon concept of XML pipelines.

As of June 2008, progress with Schematronic has picked up substantially. I’m going to try and get an instance of Schematronic running on Google’s app engine. Should be interesting!

Schematronic Design

Initialization & Startup

The Schematronic Design centers around running as a WSGI application daemon. Upon startup, the sitemap and configuration will be loaded.

Runtime Requests

Each request will reference the persistent sitemap and configuration objects. Each request will generate a flow document which can be rendered out via XSL. I think that the foundry process of Nexista, which builds php files of the parsed XML data, can be done programmatically with python reflection, fast enough to bypass the foundry process. Along these lines, the Nexista handlers will be the most important modules to port, when getting Schematronic up and running.

WSGI Applications?

Should each of the handlers / components be WSGI applications?

Development

Development of Schematronic applications will be pretty much like Nexista apps, though a lot more “pythonic”. Loosely coupled, modular, and WSGI compatible… hopefully. Luckily there are already a bunch of WSGI middleware modules which might be usable for Schematronic.

Related Concepts

• Caching
• Authentication / Authorization / Sessions
• Error / Exception Handling
• Debugging
• XML Parsing
• RESTful Request Routing
• Output buffering

Right now I'm definitely leaning towards simply porting Nexista to python in the form of Schematronic, instead of trying to blend nexista with cocoon, as I had originally planned.

I have a hard time understanding Cocoon because it is so big, complicated, and written in java, a language which I have very little experience with.

Furthermore, the author of pycoon, Andrey, seems to have a good understanding of python and cocoon, whereas I am learning python, but have a good understanding of nexista.

Once I'm done with Schematronic, I'll be more familiar with python, and will then hopefully understand pycoon better. I should also have another look at popoon, as it is a PHP port of cocoon. I've looked at it before and unfortunately I got confused pretty quickly. Maybe this time around I'll be able to understand it better as I've learned a little bit about cocoon while exploring pycoon.

Nexista

I installed mod_wsgi and really like it a lot. Its a lot like mod_fcgid in some ways, and is really helping me experiment with serving python-powered content. Cool!

When working on Nexista, I started to architect applications like PBooks so that each main part would have a separate entry point. For example, to login, you would access the auth.php script, and the various functions and resources could be accessed with keys, like auth.php?nid=login. Once you logged in to the application, you would interface with the pbooks.php entry gateway, and access its functions and resources in the same manner.

This jives very well with mod_wsgi and the plans I have for Schematronic. I'm still on the fence about how much I want Schematronic to be like Nexista or Cocoon / Pycoon, as I'm more familiar with Nexista, but Cocoon is bigger and has more support.