-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 =pod I haven't had much to blog about recently, but here are a few tidbits you might enjoy while I think of something more interesting to write about. =head2 Component->config is write-only People seem to forget this all the time. Good use of C: lang:Perl package MyApp::Model::Something; use base 'Catalyst::Model'; __PACKAGE__->config( static => 'data' ); Bad use of C: package MyApp::Model::Something; ... sub method { my $self = shift; $self->config->{some_key}; # XXX } You can't read from C. Everything in config gets merged into C<$self> at C time: sub method { my $self = shift; $self->{some_key}; # correct } Note that there are many ways to get configuration into a component. You saw one, C<< __PACKAGE__->config( key => value, ... ) >> above. Some others: package MyApp; use Catalyst; __PACKAGE__->config->{Model::Something} = { some_key => 'some value' }; If you use ConfigLoader with YAML, you can do this too: --- Model::Something: some_key: 'some value' TMTOWTDI. I generally don't put anything critical in the config file, though, because I don't want users to touch that stuff. =head2 Common configuration If you have an app that consists of more than just the Catalyst part, you might find sharing a ConfigLoader-loaded config between the components troublesome. The solution is to write a config class like: package MyApp::Config ... load config ... sub get_catalyst_config { my ($class) = @_; return %{$class->{config}}; # or whatever } Then you can easily use it in Catalyst: package MyApp::Web; use MyApp::Config; use Catalyst qw(...); __PACKAGE__->config( MyApp::Config->get_catalyst_config ); This technique was suggested to me by Dave Rolsky after I released C, which replaces C<< $c->config >> (and C<< $c->stash >>, if requested) with a class of your choice. Since C<< $c->config >> is read-only after C, HashClass (for config) isn't all that useful. Feel free to use it if you want to add accessors to C<< $c->config >>, though. (So you can write C<< $c->config->foo >> instead of C<< $c->config->{foo} >>.) =head2 Deploying your DBIC Schema DBIx::Class lets you deploy your DBIC schema to a database: use My::Schema; My::Schema->connect('DBI:...')->deploy; That's a lot of code to write, though, so there is a module called C on the CPAN that includes a script called C. If you have that, you can just say: dbicdeploy -Ilib My::Schema DBI:whatever:database That's much quicker than writing a script. You can also generate files containing the necessary SQL: dbicdeploy -Ilib My::Schema my_schema Convenient. =head2 Testing your DBIC Schema Using a database in unit tests used to be painful, but with DBIC it's a breeze. Install C from the CPAN, and then you can: use Test::More tests => ...; use DBICx::TestDatabase; my $schema = DBICx::TestDatabase->new('My::Schema'); Now C<$schema> is a fresh C you can use. Behind the scenes, C creates a temporary SQLite database, deploys to it, and returns the connection. It handles cleanup for you, so you don't have to do anything. Just use the database as you see fit, and it will go away when you exit. =head2 Bash alias for running the Catalyst server I find myself switching between the 6 or so Cat apps I maintain fairly frequently, so C<< perl script/myapp_server.pl >> never seems to be nearby in history. To combat this problem, I have a bash alias that looks like: lang:Bash alias cs='perl script/*_server.pl' Then I can just type C<< cs -r -d >> anywhere and get a catalyst server for the app I'm working on. Anyway, that's all for tonight. Have fun. =cut -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iQCVAwUBRwx3vNAZeFPdJeQvAQITfAQAqopgnz2XAvbofBiJPHA7lv4R5vLxnt2i 0j9v604to7aGwI5Ac2Q3d0ArCm8emvd8vpnlv+1AyDcPDI3RMSGpHZJA80zyioq/ rv6X9YgBYAHhkzsi1cYKwQVc6Z3/OaP0lLAMNl5etWtSuX9GG+dZE16QAiUJOYLH bNUifz7q0Xg= =q/qP -----END PGP SIGNATURE-----