Dev411 Blog

I've worked on a number of database-driven projects and no matter how much people want database abstraction, it was always difficult to code and maintain. I was recently reminded of this when I read this Drupal article on dropping PostgreSQL support. Not only can it be difficult to maintain support for multiple databases, but it may be difficult to find developers.

One solution of modern programming is to move database abstraction from the code to the infrastructure using a ORM (Object-Relational Mapper) or Data Mapper. A ORM and Data Mapper abstracts the database for you so you no longer have to do tie db abstraction to each app. Not only does it let you code once for multiple databases it lets your users migrate their data from one database to another. This blog runs Typo which is based on Ruby on Rails and ActiveRecord. I've been contemplating migrating Typo from MySQL to PostgreSQL and I've been told that it would be as simple as exporting the data with YAML, updating the database.yml file and importing the data. I haven't gotten around to doing it yet but it is a powerful idea. ActiveRecord is a data mapper and isn't as flexible as a full blown ORM but it gets the job done for the most part. For a full-blown ORM, I think of Perl's DBIx::Class which provides a full OO interface to the RDBMS allowing you to code just once for multiple DBs without limiting you when you want to use some esoteric database-specific SQL. DBIx::Class is often used with the Catalyst Framework but is also used by itself.

There are PHP frameworks out there like Symfony and Cake but do any of them have stand-alone ORMs? If so, could Drupal move to something like that and solve their maintainership problems once and for all? Drupal is part of the Go PHP5 effort so there should be no issue using PHP 5 OO. Something to think about for the Drupal folks if a PHP ORM is available.

If you are running a site without a subdomain, e.g. http://dev411.com and need to maintain cookie-based sessions across other server names with subdomains, e.g. blog.dev411.com and wiki.dev411.com, you will need to customize your session cookies.

To have your session cookie be used across multiple subdomains, set a wildcard domain which starts with a dot followed by the base domain name, e.g. ".dev411.com", which will make it qualify for all subdomains of dev411.com. This, however, will not work for http://dev411.com where there is no subdomain.

The have the same session used for http://dev411.com, set a second session cookie without domain. This way the domain-less cookie will be used for http://dev411.com and the wildcard domain cookie will be used for all subdomains.

Catalyst 5.7007 will only set one cookie per cookie name, however, this solution works best when you can set both cookies with the same name but different cookie domains. I put together a quick patch for Catalyst::Engine to allow multiple cookies when the cookie value is set to an arrayref.

Whenever popular Perl sites are discussed, a number of large websites are mentioned with the usual suspects being Amazon, IMDB, LiveJournal, Slashdot and others. While this is a good list, what often doesn't get mentioned is the new Web 2.0 sites that Perl 5 is powering. Perl 5 web frameworks (such as Catalyst and Jifty), OO models (Moose) and other techniques (PAR) dramatically improve Perl for web development and large-scale projects making many complaints about the language irrelevant. These, when combined with CPAN, continue to make Perl 5 a very attractive language for new web apps.

Examples of Perl-powered Web 2.0 sites include del.icio.us, (which uses the Mason templating system / mini-framework), EditGrid (an AJAX-enhanced online spreadsheet running on the Catalyst framework) and Vox (a multi-user blogging site by Six Apart, maker of LiveJournal, MovableType and TypePad). Other sites include HiveMinder, IUseThis, and MighTyV. Of these six sites, four are running on the Catalyst framework. HiveMinder is built on the Jifty framework. Yahoo is even interested in developers with Perl/Catalyst skills along with C and Java for this Senior Software Engineering position (screenshot from jobs.perl.org). Screenshots and links of active sites are provided below.

del.icio.us Description: Social Bookmarking Perl Framework: Mason

EditGrid Description: Online Spreadsheets Perl Framework: Catalyst

I just set up Planet Catalyst at http://planet.catalystframework.org to aggregate blogs about the Catalyst MVC framework. It is also linked from the main Catalyst homepage and Planet Perl so you can reach it from there. The planet is focused on articles related to Catalyst and friends which means it filters articles on catalyst, dbic, dbix(::|-)?class or html(::|-)?widget, h::w or handel (case insensitive). Let me know if there are any other topics of interest that should be included.

Planet Catalyst is powered by Plagger, a Perl-based RSS/Atom feed aggregator. Thanks to Tatsuhiko Miyagawa for writing Plagger and answering my questions on the #plagger FreeNode IRC channel. It was very easy to add filtering on keywords by specifying a rule in the config file.

If you have questions or would like a blog added, send email to the catalyst-dev mailing list, comment on this article or ask on #catalyst / #catalyst-dev perl.org IRC channels.

Often times you'll want to customize your response specific to the View being used, e.g. setting extra headers. This can be done directly in your View class by creating a process method. All View base classes have a process method defined in Catalyst::View that gets called at rendering time. By adding a process method in your subclass and redispatching to the parent you can do some preliminary processing.

Jim Ley reports on the Google JSON XSS exploit with example code and screen shots of stealing information from the AdSense site. The moral of the story is don't use text/html for the MIME type when returning JSON, use application/json which is an IETF standard (RFC 4627) now. Most browsers should handle application/json fine, however Opera may have problems and you may want to use application/x-javascript for that. Something to remember even if your AJAX code/library doesn't care about the MIME type returned by the server, e.g. Dojo.

If you are using Catalyst and Catalyst::View::JSON, your JSON response will automatically be set to application/json for all user agents except Opera (which gets application/x-javascript) so you're already safe(r).

I just migrated my Catalyst app to use GD instead of ImageMagick based on some reported compatibility issues.

• Chris Laco reported Apache2/mod_perl2 would core dump with ImageMagick (on FreeBSD). He moved to FastCGI+ImageMagick first and is now using FastCGI+Imager. ImageMagick has been reported to work with Mason+Apache1.x+mod_perl1.3.
• Andreas Marienborg reported on #catalyst IRC that Imager doesn't work with Catalyst+PAR and has moved to GD.
• Someone on #rubyonrails IRC mentioned having problems with RMagick and was looking to migrate to ruby-gd

Wanting the best of all worlds, I moved to GD which also has a smaller memory footprint than ImageMagick. I ended up writing my own wrapper for Lincoln Stein's GD module using the Image::Magick API (drop-in replacement for a very limited set of functionality) though something like Image::Thumbnail, which provides a uniform interface to GD, ImageMagick and Imager, is probably better for general use.

Thanks to Chris and Andreas for their reporting issues. Hopefully I'll be all set with GD.

A new major version of the Catalyst framework has just been released. Read about it on Digg; here are the latest results I've seen:

It actually got to 91 diggs at the top of the Digg homepage before a new article came along (I took screen shots in KDE too but the layout wasn't as nice as XP). From Jezmo's Digg comment, I learned that SomethingAwful (6th largest forum on the Internet) is using Catalyst to build Titan, a schema-compatible vBulletin replacement. Catalyst is also used by Dresdner Bank, IUseThis and EditGrid.

Marcus has an announcement on his blog and the change log is available, but I'll summarize the changes here:

• "ActionClass templates" which allow you to make extensible actions. The first of which is Catalyst::Action::RenderView, a more flexible replacement for the DefaultEnd plugin. Read more about this in Catalyst::Manual::Actions.
• "Chained actions" which allow you to have parent and child actions on a uri. For example in a uri like /page/43/revision/23/edit you could have one action handle /page/43 and another handle revision/23/edit with captures for 43, 23 and edit.

• Major documentation improvements including the Tutorial and Introduction parts of the Catalyst manual, reference API documentation and the Cookbook.
• More concise log info and new colors for the debug screen.
• Switch from Module::Pluggable::Fast to Module::Pluggable for more fine grain control over setup_components.

• The Catalyst distribution has been split into Catalyst::Runtime and Catalyst::Devel. Runtime contains the minimal parts for deployment while Devel includes helpers and tools. Thankfully install Catalyst in CPAN will install Catalyst::Runtime and there's no need to change the use Catalyst; lines in your App Classes.

• Catalyst::Engine::Apache FIRSTKEY error: I just upgraded from Catalyst 5.6902 and Catalyst::Engine::Apache 1.06. I didn't have a problem running 5.6902 and 1.06 but others had the generic problem below and previously upgraded to 1.07. The problem only appeared with 5.7000 and 1.06 for me. In any event, make sure you're running Catalyst::Engine::Apache 1.07.

  [error] Caught exception in engine "Can't locate
    object method "FIRSTKEY" via package "APR::Table" at
    /path/to/site_perl/5.8.7/Catalyst/Engine/Apache.pm 
    line 65."

I played with Catalyst::Plugin::I18N today to test returning text according to the user's language. This is called internationalization (I18N) or localization (L10N). I prefer the term localization when customizing output for users for this (and internationalization for storing multi-lingual data in the backend) but the definition is subject to debate and both are used. It seems there are two stages to L10N: locale detection and the localization.

C::P::I18N can do dection based on an explicit setting:

$c->languages( ['de'] );

or automatic browser detection based on the browser's HTTP_ACCEPT_LANGUAGE. C::P::I18N does the localization portion using string substitution. To set this up put your string definitions in the your mo/po or Maketext classes and then localize in the View, for example using TT:

[% c.loc('Hello World') %]

Also make sure to set the Vary header to assist with caching:

# Covers one or more Vary headers
$c->res->headers->push_header(
    Vary => 'Accept-Language'
);

# If you only have one Vary header
$c->res->header( Vary => 'Accept-Language' );

The Vary header should theoretically handle proxy caching though these servers are typically out of your control and cannot be guaranteed to recognize and process the header.

The other popular detection option seems to be to put the locale in the URI, either in the domain name (e.g. http://www.mysite.cn) or in the path / query string, as opposed to reading a HTTP request parameter.

Cal Henderson's Building Scalable Websites O'Reilly book talks about Localization and mentions three methods:

1. string substitution
2. multiple template sets
3. multiple frontends

Cal mentions all three methods are hard and doesn't give an outright recommendation. He does, however, lists problems with string substitution and multple template sets but not multiple frontends so perhaps he's implicitly recommending the latter. He doesn't talk about detection methods. At first I was very excited to get Cal's book because I thought he would make outright recommendations. I'm starting to realize it's more of a primer and you have to tease out the best option.

Do you L10N or I18N? If so, how do you do it?

HTML::Prototype is by far the most painless way to get started with AJAX that I've found. Simply put, you do not need to know or write any JavaScript! HTML::Prototype is a Perl module on CPAN that wraps the prototype AJAX library and Script.aculo.us effects library with Perl helper methods so you don't need to write a single line of JavaScript to get some great effects. There are also a number of modules that wrap HTML::Prototype for integration with Catalyst, CGI::Application, Template Toolkit and others.

There are a number of convenient methods such as link_to_remote() and submit_to_remote() that create a link and form button to make an AJAX call and populate the innerHTML of a specified DOM element with the response body. Syntactic sugar to be sure as the JS generated by HTML::Prototype is very simple once you look at it, but the beauty is that you never have to.

To truly appreciate HTML::Prototype you need to use some of Scriptaculous' more advanced widgets such as autocomplete. Sebastian Riedel put together a screencast using Catalyst that demonstrates how easy it is to use. Links to the screencast are available on the Catalyst wiki movies page:

http://dev.catalyst.perl.org/wiki/Movies

Another great thing about having HTML::Prototype generate the JS syntax for you is that you can learn prototype syntax just by View Source. I picked up enough of prototype's JS syntax this way that I haven't looked at the docs yet.

I've recently removed HTML::Prototype from a project in favor of using prototype.js and scriptaculous.js directly and I'm evaluating the Dojo Toolkit but HTML::Prototype let me get started with very effective, painless AJAX functionality. I used it with Catalyst::Plugin::Prototype and thought 'this is how frameworks make you productive.' Thanks to all the contributors.