It’s been several months since I’ve had a chance to update The Great Web Framework Shootout, but this weekend I decided that it was time to dig in and freshen things up a bit.
Not only have most of the frameworks seen new releases since the last revision, but I finally decided to move all of the tests over to Amazon’s “release” version of the Ubuntu LTS AMI.
Below is a quick summary of what’s new in this revision:
- All tests were performed on the updated Ubuntu LTS AMI (ami-fbbf7892 ubuntu-images-us/ubuntu-lucid-10.04-amd64-server-20110719.manifest.xml)
- The updated AMI was configured with Python 2.6.5, PHP 5.3.2, Ruby 1.9.2p290, Apache 2.2.14 (default config), mod_wsgi 2.8 (embedded mode), and mod_passenger 3.0.9
- Rails 2.x and 3.0 were dropped from the “full stack(ish)” tests in favor of Rails 3.1.
- CakePHP 1.2 was dropped from the PHP tests in favor of 1.3, but Symfony and Yii were added as they seem to have considerable market share.
- CakePHP’s caching engine was incorrectly configured during the last round of tests, and this has been corrected.
Circle me on Google+ to keep track of further updates, and feel free to contact me there with any questions or comments.
[Note: Due to the popularity of these posts, I have decided to move all of the benchmarking information over to its own dedicated page. Please see the new framework shootout page for the latest information.]
While I had originally intended for round 4 to showcase how microframeworks are changing the way we do “quick and dirty” web development (and how they make using PHP as “an extension to HTML” old hat), my current programming habits have kept me involved in the more “full-stack” framework solutions. So, rather than spitting out various benchmarks of frameworks that I have little or no interaction with, and since enough time has passed since the last “shootout” that the landscape has changed a bit (with the introduction of Pyramid and the release of Rails 3), I have instead decided to showcase the most recent data on the frameworks that I personally find myself in contact with on a regular basis. (continue reading…)
I recently had to implement pagination in a TG 2 project that I’m almost finished with. Although I had previously glanced at the paginate webhelper module, I first turned to the updated TurboGears documentation to see what was “officially” written up about this subject.
A lot of work has been going into the TG docs in preparation for the upcoming v2.1 launch, and one little gem that was recently added was the Pagination Quickstart (thanks Lukas). While this sent me down the right path towards pagination perfection, there were a few things that came up that I felt like deserved further explanation:
- The @paginate() decorator is an extremely simple wrapper for the paginate webhelper module.
- When paginating SQLAlchemy queries, paginate runs a duplicate count() query to figure out its current position in the data collection. While the magic of this is nice, the possible performance issues with duplicating complex SQL queries on a high-traffic website could be undesirable.
- It’s common to have controller methods dynamically switch to a “feed template” when doing AJAX pagination. Don’t worry, paginate + override_template makes this a piece of cake!
The @paginate() decorator makes pagination a breeze
The @paginate decorator is a wrapper for the paginate module that can be added to your controller methods. Simply specify your data collection’s name as the first argument of the decorator, and pagination is “automagically” setup for you.
An example controller method with pagination would look like this:
# dead-simple pagination in TurboGears 2 @expose('myproject.templates.posts') @paginate("posts") def posts(self): posts = DBSession.query(Posts) return dict(posts=posts)
Really? That was easy!
The documentation on this decorator seems quite clear to me, so instead of repeating its content here I will simply give you a link for further reading.