While working on the MVC Marathon series, I was totally bummed that Catalyst lacked a truly decent CRUD for administrating data like Django and others have. Either it was full CRUD for Rose::DB, or Class::DBI, or bits and pieces that needs a fair amount of coding.
Then along came CLFB. The interface rocks, and the recent changes to both run it as a plugin in and existing app and move its magic into a namespace like /admin totally makes this a winner for the Cat+DBIC community.
Just what I needed. Not only for Models/Views, this component is also great when building base controllers that others will use. It allows you to allow people to call your base class methods directly without having to 'forward' to them, or pass $c in the params.
This module is great for testing situations where code uses the first available module it finds from group of modules. No we can exercise that code and still make sure all of the compatible modules work as intended when chosen.
This module just managed to shave off a good chunk of time from my 10k plus Handel test suite. That alone makes it gold. I can't wait to see the effect this and the changes in 5.9/5.10 have on DBIC/Catalyst.
THe only reason it's not all 5s is that I just haven't used it yet. But this module, coupled with M::I::Share is exactly what I want to accomplish for splitting a CPAN dist into it's dist-static parts and local user overridable parts in terms of static css/js files, templates and other non-image files.
This goes out to all modules like Test::Warnings, Test::Strict, Test::Spelling, etc, but is focused at Perl::Critic directly. These tools are invaluable to me as a perl developer. I tell them how I expect myself and others to code in my dists, and Perl::Critic keeps me honest about those things. Sometimes I'm just lazy. Sometimes I just forget. Perl::Critic is neither.
I've been waiting for a test module like this for a while to help me keep my manifest up to date since I almost never do make manifest. It would be nice if you could tell it which directories to ignore. For example, some dists create scratch files in t/var when running tests. There's no reason to compared that directory to manifest since things in there are no permanent.
As a side note, is there any good reason why Makefile.PL has use 5.008006; in it?
I'm in the process of converting Handel from CDBI to DBIC schemas. There is almost nothing you can't tweak, change, modify, or redirect about the various logic and behaviors of how DBIC operates on your data. DBIC makes the tedious things easy, and the complicated things quite possible.
While working on Handel, I've come to the point where I need a sane way to create SQL scripts for multiple database. SQL::Translater is making my life more sane in this area. Once I define the schema, I can just have it toss out create scripts for SQLite/MySQL/Postgres and go on with life. This pays off even more when I want to define foreign key relationships, but only some platforms support them; or support them in different ways.
On the flip side, I wish the docs were a little more verbose about the formats, especially the YAML producer.