Your Linux Data Center Experts

This weekend at bazcamp, I was playing with two web frameworks: Django (which I've been calling “Duh Jango”, despite my suspicion that it's meant to be just a silent D), and Myghty. In short, Myghty is a Python implementation of Perl's Mason, and Django is something that is what I imagine Ruby on Rails is like. Read on for more information on what I found.

Myghty is in general pretty straightforward. For things like putting Python in HTML, it's very obvious. However, there are some subtleties that have tripped me up. For example, sometimes I can't reference ARGS (the global that's supposed to hold form data). While the documentation is fairly good, I seem to spend a lot of time trying to hunt down things.

Integrating Python code into Myghty pages is quite easy. You can in-line code, or call out to Python module in another directory to get it if you prefer. You can use model/view semantics if you like, but you don't have to. I like model/view for some things, and hate it for others. Myghty is also very easy to set up and get working in quickly. Setting up a virtual host to test out Myghty code is very easy by following the documentation, where Django I had many more problems with because their example Apache configs for mod_python are fairly incomplete. They just show a Location stanza, but not how to set up the whole VirtualHost, so I had to think about it for a while to get it right.

One thing you'll notice from the documentation is that the Myghty documentation is all pretty low-level where the Django documentation is all pretty high level. Let me assure you that that carries over into the systems themselves. Myghty is a very low-level tool, and I think it's pretty good at that. Much like back in the mid-1990's when I was looking for a replacement for C because it was too low-level and I was tired of doing realloc()/strcat()/free() sorts of things, Myghty is really too low-level for what I want.

Django is very much more a high-level tool. In the tutorial, you start off by defining the database schema in your “model”, and then you run some code that creates the database tables from that model, sets up your directory structure, etc… You then specify a list of regular expressions which match the URL (including arguments from the URL including the (?P) syntax for turning parts of the URL into arguments to pass to your views.

For example: r'^users/(?P[^/]+)/(?.*).html' when hit with the URL “http://example.com/users/jafo/about.html” will call the view with username=“jafo” and pagename=“about”. You specify a python function which implements the view, and returns the page data. You could have it “SELECT body FROM userpages WHERE username = %(username)s AND pagename = %(pagename)s”.

Django includes a number of “generic views” which do things like show a list of the elements in your database (including sorting by any field in the table, searching, etc), show a particular record, and create a new record or edit an existing one. These generic views allow you to very quickly come up to speed for very common tasks. If you need to “take the stick”, and do something different, it's not too bad.

Django includes an “admin” interface in which you can interact with your site. This includes making use of your model by adding or manipulating your model, managing users and groups (which the tutorial goes into absolutely not at all) and also some other functions similarly un-tutorialized. This is an easy way to add some initial data to play with for your views. The sample includes a “polls” table which includes a question and a date, and choices which are linked to the polls that have a “votes” field and a value. The example doesn't use a “DEFAULT 0” in the model, which is unfortunate, because it works great.

So, once you've defined your model, you can then go in to the admin interface and create a sample poll or two, and set up some choices for them. The next step is to create the public views. These involve setting up (largely) HTML templates and creating one view for processing the new record submission related to voting in the sample poll. This isn't a generic view because it needs to do two lookups on the two tables, then do an increment of a value in the other. This is different than simply editing an existing record or creating a new record (both of which there is a generic view for).

So, I followed the tutorial, and was pretty happy at the high level that I was working at. Then I walked through it with Evelyn, and she said that it was very like what she had seen in Ruby on Rails, but the thing she couldn't tell from her time playing with Rails was, how hard is it to do something else. So, she asked me how I would go about showing a percentage of the results. I was already showing the vote name and how many times it had been voted for. “Boy, I don't know” I said…

After thinking about it for a moment, I decided it should be very easy: just add a “totalvotes” field to the Poll object (row in the database). That part was easy, but then making use of it was not so easy because I was thinking of things wrong. You can create custom tags, and there's a tag for “widthpercent”, which can be used with an image to show a bar of appropriate length. Building your own tag is real work though. I finally realized that I really needed to augment the model with a “percent” method, and that was real easy.

So, in short, Myghty looks pretty solid, and is obviously built off of a mature idea (Perl::Mason), but Django looks to be operating at the higher level that I really would like to be dealing with. I've just started scratching the surface of the form handling, but it's looking pretty nice. It's definitely worth a look if you are interested in web development using Python. Myghty is pretty good if you are looking for a more traditional templating environment and don't want to have to worry about models. I'm ok with the models, it's just the views I'm not sure I want to deal with. The generic views get me started though.

comments powered by Disqus

Join our other satisfied clients. Contact us today.