Allan Saddi's projects blog

You know a project is getting serious when you create a Trac site and a blog category for it.

So I've been hammering away at this thing for the past 3-4 days. I'm surprised to say that it's actually in a working state now. Maybe functional enough to be classified as a 'toy' web framework? Well, I suppose I need to finish more components first, since having only text fields for form input could get quite frustrating.

But the basics are all there... component rendering, event triggers, parameter binding (both by value and by reference), automatic persistence of session data.

Time to polish it, add more components, refine the interfaces. But I wonder... do I ever really want to publish it? Make it widely available? Document and support it?

Hmmm... I don't know.

But for now, I'd rather write code.

Related to a recent entry I've made, I started thinking about a Python port (at least in concept) of Tapestry. Rather than go for the template/spec/class approach of Tapestry 4, I opted to go for the wholly annotation-based approach of Tapestry 5 (still in development) thus eliminating the need for a spec file.

Annotating methods/functions in Python is pretty simple, just use decorators. Annotating member variables, on the other hand, seemed non-trivial. But then I remembered ORMs like SQLObject and SQLAlchemy and that gave me an idea. However, it would require metaclass magic...

So when I woke up this morning, I grabbed my laptop and started hacking away at a proof-of-concept (while still in bed!) Many hours later (and I did get out of bed, eventually), I had most of the metaclass infrastructure for flannel done. Yes, flannel. (I'm entertaining ideas for a better name though.)

So now I can easily mark variables as a persistent, transient, or parameter type. And the variables will be magically transformed into a Python property with my own setters and getters. Also, I can mark methods with certain "lifecycle decorators" which defines when during the rendering cycle they should be called. Basically something like:

class MyComponent(BaseComponent):
  value1 = Persistent()
  value2 = Transient(42)
  param1 = Parameter('foo')
  param2 = Parameter(required=True)

  @setup_render
  def do_something(self, out):
    pass

Transient variables don't really need to be annotated... but doing so allows them to be reset to an initial value at the start of a processing cycle. Speaking of which, if you aren't familiar with Tapestry, the abbreviated request/response cycle I'm aiming for looks something like:

1. Figure out which page/component the request was targetting via PATH_INFO.
   
2. Get an instance of the page from the pool.
   
3. Restore persistent variables from storage (typically the session), reset transient variables to their initial values, bind parameter variables and ensure all required parameter variables are bound.
   
4. Render the page! (Which recursively renders components within.)
   
5. Save persistent variables to storage.
   
6. Return page to pool.
   

Actions or pages with forms would require slightly different handling, which I haven't thought about yet. Form handling, I think, is the strength of these event-driven frameworks... so I'm aiming to get it right. Basically you "bind" input components (like text fields, checkboxes, etc.) to properties or even property paths and give it an "event handler" to call when the form is submitted. When your event handler is called, you can expect the properties to reflect the user input.

Anyhow, a significant (and unfortunate, I think) part of this project will involve coming up with yet another templating engine. However, it should be a fairly simple tag-based system, since most of the functionality will actually be implemented by components.

It will be interesting. Though I don't expect to take this project very seriously. But maybe if/when I actually get it to where I want it to be, I'll change my mind.

I added FCGIApp and SCGIApp to the (new) flup.client package. I wrote FCGIApp a few months ago for Ian Bicking's WPHP. While attempting to debug a problem with flup's fcgi server on Dreamhost (vs. my old fcgi.py module), I thought of an interesting solution.

Since the problem seemed to stem from the app's long startup time, and since Dreamhost only allows dynamic (i.e. web server-launched) FastCGI apps, why not have the web server-started app be as simple as possible and have it forward requests to a static, manually-launched app server?

In other words:

httpd (mod_fastcgi) -> fcgi.WSGIServer -> FCGIApp -> fcgi.WSGIServer -> app

Yeah, it ends up doing some extra work... which is why I wrote SCGIApp (SCGI is a far simpler protocol):

httpd (mod_fastcgi) -> fcgi.WSGIServer -> SCGIApp -> scgi.WSGIServer -> app

Anyway, it's a trade off and I really don't know how significant it is. But I was never really a fan of web server-launched FastCGI apps. Unless you configure mod_fastcgi explicitly, it has a tendency to launch an application multiple times. And if your application isn't multi-process safe and aware, it can lead to problems.

Consider these two modules experimental for now. I'm not really sure where I want them to live. But they're there for the time being to play around with.

Nothing about Python per-se, but applications/frameworks written in Python that I wish I could find. (And that weren't related to Zope/Plone!)

• A Python portal framework. Perhaps even a standardized Python portlet specification, to facilitate this.


• Similarly, a Python CMS, along the lines of Drupal and Joomla! Is there one?


• A web framework similar to Tapestry (and therefore, similar to WebObjects). But perhaps more Pythonic, whatever that means within that context.

I'm contemplating starting one of those projects myself. But I've been so out of touch with the Python community. Supporting flup has been almost nightmarish lately. (I guess I'm just too nice... it is OSS afterall.)

Poor flup. Reviled and yet seemingly a necessary evil because it was one of the first. (But thankfully, no longer the only choice as more FastCGI servers are released.)

Whatever. Winter break is coming up. I should have time to work on something.

I briefly toyed with Trac some time ago. Though I had to patch it to use WSGI, I found it pretty easy to use and maintain. My efforts eventually stalled, however, probably due to the way my public repository was derived from my real repository (i.e. lots of empty changesets).

Anyway, yesterday I updated to Trac 0.10.2 and was pleasantly surprised to find that it supported WSGI and flup's ajp and scgi servers out-of-the-box. The empty changeset issue is still there (which is my problem to fix). I just might have to split my repository up in the future.

Anyhow, flup has its own Trac site now:

http://trac.saddi.com/flup

The old flup site, http://www.saddi.com/software/flup/ simply redirects there now. (And will probably do so for the foreseeable future.) Please continue to use this URL when referencing flup.

I locked down all the default pages, but all the flup-related pages (save for the front page) are editable by anyone. So feel free to contribute examples, FAQs, etc.

I guess.

I've worked on my Python "blog" project for a number of years now. If I remember correctly, under the hood, it started out using flat files for storage and CGI. Eventually I moved it to mod_python+Publisher, then to FastCGI+my own version of Publisher. Sometime before that, I switched to using PostGreSQL... eventually transitioning the site content and then the session data to the database. (The templating engine changed at least once. And of course eventually, came the switch of the whole webserver interface to WSGI.)

Anyhow, what I was aiming for was a user-customizable blog/forum site. Multi-column, a selection of premade components (such as polls and HTML boxes), user profiles, personal bookmarks, etc. It was pretty ambitious and it met most of those goals. Though little did I realize that if I just generalized my goals a bit, I would actually be creating a Content Management System.

I didn't come to that realization until I started playing around with CMS's recently. At first, being in my Java mood, I sought open source Java CMS's. I only stumbled across Lenya. I ran into some difficulty, and promptly tabled it. I figured there would be more Java CMS's out there. But I really didn't have much luck finding anymore... (ok, so I didn't try that hard, either)

I briefly looked at Plone (based on Zope). It seemed a bit overkill for what I wanted... and overtly complex. So I moved on the PHP-based projects. (Note that I eventually did try Plone. But my gut feeling was correct, especially compared to the PHP CMS's.)

So I decided to look at Joomla! and Drupal, based on all the hype around those projects. (Some of it good, some of it bad... i.e. security vulnerabilities that made the front page of Slashdot. )

I tried Drupal first and immediately fell in love. It was utterly simple to use and maintain. It was a breeze to set up multiple instances using the same installation. It had a whole array of 3rd party modules that did what I wanted. (And I found, it could do most of what I wanted out of the box already - I just had to enable the module.) Anyhow, I switched 3 of my (static) sites to Drupal to try it out.

Unfortunately, at this point, I never gave Joomla! a chance. I hear many good things about Joomla! pertaining to the ease of use (and the eye candy). But it had one fatal flaw in my eyes: it only supported MySQL. Hence the reason that I tried Drupal first...

As an aside, it's probably obvious, but I'm not a big fan of the L-M-P in LAMP. 1) I am and have been an avid FreeBSD user for the past decade. 2) I prefer PostGreSQL over MySQL, speed be damned. I like my transactions, thank you. 3) Whether the P stands for Perl or PHP, I'd rather have my apps written in Python and to some extent, Java.

Anyway, the only thing really missing (so far) from Drupal is a good CAPTCHA module. Solving a simple addition problem seems a bit simplistic. I'd be surprised if there weren't bots that could answer those CAPTCHAs already. And the image CAPTCHA support seems a bit lame, especially compared to the last CAPTCHA library I worked with, JCaptcha. Anyhow, I bring this up because even though I normally turn off user registration, I did forget to turn it off for one of my sites. Overnight, some 3-4 "people" (all using rather fake looking yahoo addresses) registered for my site. I'm sure if I had some actual content that you could post comments to, I'd also have a bunch of spam to take care of.

Anyway, one of the sites that was converted happens to be saddi.com. If I get more familiar/comfortable with Drupal, I'll probably be subsuming this blog into its Drupal instance.

I often heard about the Tapestry framework in passing, but I never really paid heed to it. It wasn't until I read a minor blurb about it in Rod Johnson's J2EE Development without EJB that my interest was finally piqued. Basically, it stated that Tapestry was inspired by the WebObjects' Page/Component model, something I am somewhat familiar with. Something I look back at with a certain nostalgia.

WebObjects was my first experience with a "real" web application framework. Before then, I was working with CGIs and my own cobbled-together Python modules. After proving to myself that I could indeed run it on my collocated FreeBSD server (an unsupported platform by WebObjects... not to mention by Java as well, back then), I started dabbling in Enterprise Objects/WebObjects. Eventually, I wrote a number of applications, though mostly internal.

It also gave me a chance to brush up/re-learn Java. Though WebObjects was heavily tied to the OpenStep way of doing things, just under Java (i.e. the collections were not standard Java Collections, among other things), which I didn't really like.

Anyhow, I moved on from WebObjects, preferring to do my Java web development with "frameworks" like Hibernate and Spring. But WebObjects had some neat ideas, and anything WO-inspired will always catch my attention. (For example, in Python world, there's the Modeling framework, which looks promising.)

Anyway, no where in the Tapestry site will you actually see the word WebObjects, which is probably why I glanced over it before. But having played with Tapestry now, I see the influence. And not only that, with annotations and automatic state management, Tapestry has taken the Page/Component model to another level. (And the upcoming Tapestry 5 looks even more exciting.)

But, the thing that made WebObjects development bearable was WOBuilder, the graphical, WYSIWIG page/component editor. I haven't looked at the IDE plugins for Tapestry yet, but that level of integration seems to be missing. (Editing a page/component involved editing 3 files — the class, the spec, and the html template. WOBuilder actually edited all 3 in a relatively sane manner.)

I'll probably play with Tapestry a bit more, and I've already built a template web applications for myself. Whether or not there's a decent Tapestry plugin for Eclipse will probably decide whether I'll base any future projects on it. Though you can omit the spec file using annotations in the Java class, editing the template files by hand seems a bit daunting. In fact, it reminds me, not so fondly, of my homebrew Python templating engine, HTMLpp.

Though Tapestry 5 templates seem a lot easier to write...