The first presentation I gave for the Silicon Valley Perl user’s group was on Catalyst; they had just had presentations on Dancer and Mojolicious and I thought it might be nice to show the more complex tool that everyone seemed trepidatious about using. Certainly a focus of the other talks was “See how easy it is! No unneeded stuff!” which was cool. But, at every turn, I kept thinking, “Wait, you had to write that? Catalyst would have done that for me…” (more…)
Posts Tagged ‘Catalyst’
I wrote this some time ago, and it sat in the queue and got stale. I’ve mentioned one place I’m not using Config::JFDI, but I’m using it other places and I thought it desrved a mention.
I mentioned my old framework had a way to infer which configuration file to use by examining the environment it was running in. I’ve moved to the Catalyst Way of things (more or less) and that will make things easier. A bunch of my old code can go away.
I have some useful tools to do things which do like to read the config file, too. They used the same code. They now use Config::JFDI. It reads config files the same way Catalyst does, and gives you a very similar $config object you can use to look at things with.
I did have to dig in to the sources to get it to work right, even though it’s pretty well documented.
Several times, I’ve wished I could write command-line tools to manage Catalyst applications. Those tools, invariably, needed to call some of the Catalyst functions, or at least get to the database.
I found a way, and it’s so simple it hurts. I can’t help think this is one of those things the Catalyst team will read and think, “Well, duh!” but it was never clear to me and I struggled with it for months. (more…)
My last post discussed figuring out how part of Catalyst worked. I had to put debug code in to a library and watch it run. How do you do tht?