I've never really liked dealing with creating forms. You have to write a butt load of tedious HTML, validate it, and then return error messages as needed. If you want it to be fancy and pretty, you have to write a bunch of CSS to put your error messages where you want and make them shiny. Luckily, there are things to handle this.

Being a Moose fanatic, I am most partial to the latter, HTML::FormHandler. It's extremely easy to use, and requires zero configuration file crap. You get validation as Moose types/constraints, it's very cool.

So, back to me hating having to build forms. This includes building a form for something that already has enough information to build a form from, say, a database schema. My dream has been to be able to read a database schema (preferably DBIx::Class), and generate a form based on the data types specified in said schema. This is completely doable! Heck, even I drafted up some code to get some preliminary form fields from a database. The following is from the CMS I'm working on, using HTML::FormHandler and DBIx::Class to get things done. This is extremely proof of concept code, and doesn't actually have any logic to determine what kind of form element a given schema entity should be. That, however, should be fairly trivial and I will undoubtedly be writing a follow up to that effect. Go here to check out the source: http://gist.github.com/230652. Enjoy.

So I recently decided to convert the config file for a new app I'm working on to JSON. Why? Well for one, it's a lot easier to express perl data structures in, and it's also extremely easy to read. Check it out!

{
    "name": "Fnargh",
    "Model::Database": {
        "connect_info": [
            "dbi:SQLite:fnargh.db",
            "",
            "" 
        ] 
    } ,
    "session": {
        "flash_to_stash": "1" 
    }
}

Started off a bit rocky, but thanks to http://www.jsonlint.com I was able to pick at my config file until it was valid. It formats it nicely for you as well!

The best part? You can take the perl data that you use in your Catalyst app, and do something like this:

squishface:~ dhoss$ perl -e "use JSON; print to_json({ my_data => [ 'thing1', 'thing2', 'thing3' ] });"
{"my_data":["thing1","thing2","thing3"]}

JSON formatted for your config!

Recently while working on getting tests done for Catalyst::Devel so it could be shipped, and I absolutely could not figure out how to get the test for the development server to work. So, I queried #catalyst-dev about it, and my good friend mst told me to use strace to figure out what was going on behind the scenes. In this case, I used dtruss since I'm a Mac user and for some reason the usual *nix tool doesn't work on the Mac platform.

Basically, what went down was this:

1. sudo dtruss -f prove -l t/author/optional_http-server.t
2. a whole load of rather cryptic output (see below for a snippet)
3. analysis and correction

What I found was that since the Catalyst development server is chock full of system calls that are chock full of information on what's going on (and going wrong) behind the scenes, dtruss was the perfect tool for grabbing messages being relayed between processes and not necessarily being spewed out to my terminal. Here's a small snippet of the problem area I (well, mst actually) discovered:

46665/0x117e04: stat64("/opt/local/lib/perl5/vendorperl/Catalyst/ScriptRunner.pm\0", 0x7FFF5FBFEE90, 0xFFFFFFFFFFFFFFFF) = -1 Err#2 46665/0x117e04: stat64("/opt/local/lib/perl5/5.8.9/darwin-2level/Catalyst/ScriptRunner.pmc\0", 0x7FFF5FBFEF20, 0x0) = -1 Err#2 46665/0x117e04: stat64("/opt/local/lib/perl5/5.8.9/darwin-2level/Catalyst/ScriptRunner.pm\0", 0x7FFF5FBFEE90, 0xFFFFFFFFFFFFFFFF) = -1 Err#2 46665/0x117e04: stat64("/opt/local/lib/perl5/5.8.9/Catalyst/ScriptRunner.pmc\0", 0x7FFF5FBFEF20, 0x0) = -1 Err#2 46665/0x117e04: stat64("/opt/local/lib/perl5/5.8.9/Catalyst/ScriptRunner.pm\0", 0x7FFF5FBFEE90, 0xFFFFFFFFFFFFFFFF) = -1 Err#2 46665/0x117e04: stat64("./Catalyst/ScriptRunner.pmc\0", 0x7FFF5FBFEF20, 0x0) = -1 Err#2 46665/0x117e04: stat64("./Catalyst/ScriptRunner.pm\0", 0x7FFF5FBFEE90, 0xFFFFFFFFFFFFFFFF) = -1 Err#2 46665/0x117e04: writenocancel(0x2, "Can't locate Catalyst/ScriptRunner.pm in @INC (@INC contains: /Users/dhoss/web-devel/Cat-Runtime-5.8/t/author/../../lib /Users/dhoss/web-devel/Cat-Runtime-5.8/lib /opt/local/lib/perl5/siteperl/5.8.9/darwin-2level /opt/local/lib/perl5/siteperl/5.8.9 /opt/", 0x2D0)

That's just a snippet. Somewhat cryptic, but it's all right there. Check out this line: 46665/0x117e04: writenocancel(0x2, "Can't locate Catalyst/ScriptRunner.pm in @INC (@INC contains: /Users/dhoss/web-devel/Cat-Runtime-5.8/t/author/../../lib /Users/dhoss/web-devel/Cat-Runtime-5.8/lib /opt/local/lib/perl5/siteperl/5.8.9/darwin-2level /opt/local/lib/perl5/site_perl/5.8.9 /opt/", 0x2D0). Derp! I was running this test in Catalyst::Runtime trunk/ that doesn't have my ScriptRunner classes merged yet. So, I reran this test (using dtruss -f again) under my branch, found out that the options being passed to the development server were incorrect, corrected, svn committed, and can now take another step (finally) toward shipping Catalyst::Devel!

There's a new kid on the block for web application development, and it's called Plack. I'm not going to go into depth on explaining it here, as the website listed previously does a stellar job of that, but I'm going to explain and talk about what got me started on it, and what made me love it.

I've been a pretty avid MovableType fan since I first got it running. It Just Works(tm). I've always ran it under Apache, however, so when I made the big and permanent transition to nginx, I was befuddled as to how to get it to run under my new toy. A kind sir by the name of Jay Shirley recommended I use Plack to get my old love running under nginx. I talked to the creator of this mystical new being, Tatsuhiko Miyagawa on its IRC channel, #plack. We went back and forth for a few iterations until w(h)e got his mt.psgi script (listed here) working so that MT would be okay with new installs.

The result: A mostly working MovableType installation! The only problem is, I have a MT database dump from MySQL that I either A) need to convert the data portion of the dump to something PostgreSQL (what I've converted to for life) will like, or B) suck it up and set up a MySQL instance for this one app. MT itself runs just fine, it's completely my fault that anything on the database side doesn't work. Miyagawa reports that previous installations work just fine with this, so, as I said, I will need to investigate which route I want to take to get this data into a database for MT.

Either way, my experience was fantastic. Plack is really easy to set up. All the work is done for you, and you can still run things under FastCGI (if you're so inclined). It's a great bridge between server software and a web application, so we're not stranded somewhere in between holding on to the connecting ends of a bridge screaming "HOLY FUCK THIS HURTS AND GOD I HOPE IT HOLDS TOGETHER IF WE HAVE TO CHANGE ANYTHING".

Kudos to you miyagawa, I'm pretty sold on using this from here on out for web apps I write in the future (mostly Catalyst based, for which we have Catalyst::Engine::PSGI!)

UPDATE: Here's the configuration I'm using for nginx: http://wiki.catalyzed.org/codesamples/dhoss/placknginxconf

Scenario

You're trying to send an email (via Catalyst::Plugin::Email, MIME::Lite, Email::Sender::Simple, your choice) and you would like to be able to stuff your canned email messages into their respective Template::Toolkit templates. One way to do this is use Catalyst::View::Email::Template, which is pretty cool, but forces you to use Catalyst::View::Email, which some people aren't too keen on. So, you can do something like this:

sub email_stuff : Local {
    my ($self, $c, $review_id) = @_;

    $c->stash(
        review_url    => $c->uri_for("/thingy/${review_id}"),
        status_msg => "Thank you for your feedback!",
        template      => 'view_all.tt2',
    );

    $c->email(
        header => [
            From    => $c->config->{'from'},
            To      => $c->config->{'to'},
            Subject => "Emaily stuff!",
        ],
        body => $c->view('TT')->render($c, 'review.tt2'),
    );

    return; 
}

The line $c->view('TT')->render($c, 'review.tt2') allows you to have your view render your template for you using all the things you put into $c->stash. Pretty cool eh?