postgresql iconcatalyst iconperl iconmysql icontypo iconphp icon

Database Abstraction - code vs infrastructure

Posted in , , , , , , Wed, 05 Sep 2007 04:38:00 GMT

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. Abstraction - code vs infrastructure digg:Database Abstraction - code vs infrastructure reddit:Database Abstraction - code vs infrastructure spurl:Database Abstraction - code vs infrastructure wists:Database Abstraction - code vs infrastructure simpy:Database Abstraction - code vs infrastructure newsvine:Database Abstraction - code vs infrastructure blinklist:Database Abstraction - code vs infrastructure furl:Database Abstraction - code vs infrastructure fark:Database Abstraction - code vs infrastructure blogmarks:Database Abstraction - code vs infrastructure Y!:Database Abstraction - code vs infrastructure smarking:Database Abstraction - code vs infrastructure magnolia:Database Abstraction - code vs infrastructure segnalo:Database Abstraction - code vs infrastructure


catalyst icon

Single Sign-On (SSO) with and without subdomains

Posted in , , Sun, 17 Jun 2007 01:06:00 GMT

If you are running a site without a subdomain, e.g. and need to maintain cookie-based sessions across other server names with subdomains, e.g. and, 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. "", which will make it qualify for all subdomains of This, however, will not work for where there is no subdomain.

The have the same session used for, set a second session cookie without domain. This way the domain-less cookie will be used for 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. Sign-On (SSO) with and without subdomains digg:Single Sign-On (SSO) with and without subdomains reddit:Single Sign-On (SSO) with and without subdomains spurl:Single Sign-On (SSO) with and without subdomains wists:Single Sign-On (SSO) with and without subdomains simpy:Single Sign-On (SSO) with and without subdomains newsvine:Single Sign-On (SSO) with and without subdomains blinklist:Single Sign-On (SSO) with and without subdomains furl:Single Sign-On (SSO) with and without subdomains fark:Single Sign-On (SSO) with and without subdomains blogmarks:Single Sign-On (SSO) with and without subdomains Y!:Single Sign-On (SSO) with and without subdomains smarking:Single Sign-On (SSO) with and without subdomains magnolia:Single Sign-On (SSO) with and without subdomains segnalo:Single Sign-On (SSO) with and without subdomains

1 comment

catalyst iconperl icon

Perl 5 - Powering Web 2.0

Posted in , Tue, 05 Sep 2006 15:07:00 GMT

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, (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 Screenshots and links of active sites are provided below.
Description: Social Bookmarking
Perl Framework: Mason
editgrid EditGrid
Description: Online Spreadsheets
Perl Framework: Catalyst
Read more... 5 - Powering Web 2.0 digg:Perl 5 - Powering Web 2.0 reddit:Perl 5 - Powering Web 2.0 spurl:Perl 5 - Powering Web 2.0 wists:Perl 5 - Powering Web 2.0 simpy:Perl 5 - Powering Web 2.0 newsvine:Perl 5 - Powering Web 2.0 blinklist:Perl 5 - Powering Web 2.0 furl:Perl 5 - Powering Web 2.0 fark:Perl 5 - Powering Web 2.0 blogmarks:Perl 5 - Powering Web 2.0 Y!:Perl 5 - Powering Web 2.0 smarking:Perl 5 - Powering Web 2.0 magnolia:Perl 5 - Powering Web 2.0 segnalo:Perl 5 - Powering Web 2.0


catalyst iconplagger icon

Planet Catalyst

Posted in , Thu, 03 Aug 2006 15:28:00 GMT

I just set up Planet Catalyst at 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 IRC channels. Catalyst digg:Planet Catalyst reddit:Planet Catalyst spurl:Planet Catalyst wists:Planet Catalyst simpy:Planet Catalyst newsvine:Planet Catalyst blinklist:Planet Catalyst furl:Planet Catalyst fark:Planet Catalyst blogmarks:Planet Catalyst Y!:Planet Catalyst smarking:Planet Catalyst magnolia:Planet Catalyst segnalo:Planet Catalyst

no comments

json iconcatalyst iconie icon

Catalyst - Customizing the view to stop IE from caching JSON

Posted in , , , Tue, 25 Jul 2006 15:49:00 GMT

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.

Read more... - Customizing the view to stop IE from caching JSON digg:Catalyst - Customizing the view to stop IE from caching JSON reddit:Catalyst - Customizing the view to stop IE from caching JSON spurl:Catalyst - Customizing the view to stop IE from caching JSON wists:Catalyst - Customizing the view to stop IE from caching JSON simpy:Catalyst - Customizing the view to stop IE from caching JSON newsvine:Catalyst - Customizing the view to stop IE from caching JSON blinklist:Catalyst - Customizing the view to stop IE from caching JSON furl:Catalyst - Customizing the view to stop IE from caching JSON fark:Catalyst - Customizing the view to stop IE from caching JSON blogmarks:Catalyst - Customizing the view to stop IE from caching JSON Y!:Catalyst - Customizing the view to stop IE from caching JSON smarking:Catalyst - Customizing the view to stop IE from caching JSON magnolia:Catalyst - Customizing the view to stop IE from caching JSON segnalo:Catalyst - Customizing the view to stop IE from caching JSON

no comments

json iconcatalyst icondojo icon

JSON XSS exploit: don't use text/html

Posted in , , , , , Tue, 25 Jul 2006 01:40:00 GMT

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). XSS exploit: don't use text/html digg:JSON XSS exploit: don't use text/html reddit:JSON XSS exploit: don't use text/html spurl:JSON XSS exploit: don't use text/html wists:JSON XSS exploit: don't use text/html simpy:JSON XSS exploit: don't use text/html newsvine:JSON XSS exploit: don't use text/html blinklist:JSON XSS exploit: don't use text/html furl:JSON XSS exploit: don't use text/html fark:JSON XSS exploit: don't use text/html blogmarks:JSON XSS exploit: don't use text/html Y!:JSON XSS exploit: don't use text/html smarking:JSON XSS exploit: don't use text/html magnolia:JSON XSS exploit: don't use text/html segnalo:JSON XSS exploit: don't use text/html


imagemagick iconcatalyst icon

Catalyst and image libraries

Posted in , Wed, 19 Jul 2006 04:05:00 GMT

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. and image libraries digg:Catalyst and image libraries reddit:Catalyst and image libraries spurl:Catalyst and image libraries wists:Catalyst and image libraries simpy:Catalyst and image libraries newsvine:Catalyst and image libraries blinklist:Catalyst and image libraries furl:Catalyst and image libraries fark:Catalyst and image libraries blogmarks:Catalyst and image libraries Y!:Catalyst and image libraries smarking:Catalyst and image libraries magnolia:Catalyst and image libraries segnalo:Catalyst and image libraries

no comments

catalyst icon

Catalyst 5.7000 released

Posted in Sun, 09 Jul 2006 02:36:00 GMT

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:

Catalyst 5.700 Digg status

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:

New Features
  • "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.
New Packaging
  • 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.
Upgrade Gotchas
  • 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
      line 65." 5.7000 released digg:Catalyst 5.7000 released reddit:Catalyst 5.7000 released spurl:Catalyst 5.7000 released wists:Catalyst 5.7000 released simpy:Catalyst 5.7000 released newsvine:Catalyst 5.7000 released blinklist:Catalyst 5.7000 released furl:Catalyst 5.7000 released fark:Catalyst 5.7000 released blogmarks:Catalyst 5.7000 released Y!:Catalyst 5.7000 released smarking:Catalyst 5.7000 released magnolia:Catalyst 5.7000 released segnalo:Catalyst 5.7000 released

1 comment

catalyst iconperl icon

Localization / Internationalization with Catalyst

Posted in , , Wed, 14 Jun 2006 06:06:00 GMT

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
    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. 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? / Internationalization with Catalyst digg:Localization / Internationalization with Catalyst reddit:Localization / Internationalization with Catalyst spurl:Localization / Internationalization with Catalyst wists:Localization / Internationalization with Catalyst simpy:Localization / Internationalization with Catalyst newsvine:Localization / Internationalization with Catalyst blinklist:Localization / Internationalization with Catalyst furl:Localization / Internationalization with Catalyst fark:Localization / Internationalization with Catalyst blogmarks:Localization / Internationalization with Catalyst Y!:Localization / Internationalization with Catalyst smarking:Localization / Internationalization with Catalyst magnolia:Localization / Internationalization with Catalyst segnalo:Localization / Internationalization with Catalyst


catalyst iconperl icontemplatetoolkit iconscriptaculous iconprototype icon

HTML::Prototype - AJAX Without JavaScript

Posted in , , , , , Tue, 06 Jun 2006 01:52:00 GMT

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 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:

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. - AJAX Without JavaScript digg:HTML::Prototype - AJAX Without JavaScript reddit:HTML::Prototype - AJAX Without JavaScript spurl:HTML::Prototype - AJAX Without JavaScript wists:HTML::Prototype - AJAX Without JavaScript simpy:HTML::Prototype - AJAX Without JavaScript newsvine:HTML::Prototype - AJAX Without JavaScript blinklist:HTML::Prototype - AJAX Without JavaScript furl:HTML::Prototype - AJAX Without JavaScript fark:HTML::Prototype - AJAX Without JavaScript blogmarks:HTML::Prototype - AJAX Without JavaScript Y!:HTML::Prototype - AJAX Without JavaScript smarking:HTML::Prototype - AJAX Without JavaScript magnolia:HTML::Prototype - AJAX Without JavaScript segnalo:HTML::Prototype - AJAX Without JavaScript

no comments

Older posts: 1 2