That said, the best in Perl is probably Catalyst + DBIx::Class (what I use) or Rose (which is more than just Rose::DB).

Perl doesn't glue that easily, and for good reason.

Just out of curiosity... Could you please elaborate? :-)

First off, this will not be talking about the relative power of the Perl programming language vs. any of the others. I feel that there are several languages in common use that are more powerful than Perl 5, such as Javascript and Ruby. This, in large part, has been the impetus for Perl 6.

The reason Perl doesn't tend to glue that easily is because of Perl's historical usage. Initially, Perl was designed to be a better awk and sed. This meant that Perl became one of the best C-style text processing languages. Because of this, Perl was destined for two primary niches - sysadmin quickie tasks and the Web. I have always felt that, despite the tremendous amount of Perl CGI written over all of history, the first niche is really where the most Perl has been written.

Now, you would think that the amount of Perl CGI written would have meant that Perl itself would be better adapted to gluing a browser to a database. Except, Perl was the first. Just like the US and 110V AC vs. the rest of the world with 220V DC, being first means you make the big mistakes that everyone else learns from. And, the people who tend to write Perl have historically tended to prefer the Unix style of chainable modules vs. the Windows style of a large API that does everything. This probably is because many of the early CGI programmers were those sysadmins who knew Perl to begin with. So, they just built what they knew.

There's nothing wrong with a huge API. PHP and RoR both have it and it works great for them. Catalyst does something similar and I think the catdev team is both phenomenal and on the right track. It's just not in the Perl tradition.

What is in the Perl tradition, however, is what will happen in Perl 6. You will be able to build in that huge API directly into the language through your module. So, if you want to have MySQL support hardcoded into the language (a la PHP), you can. :-)

---

My criteria for good software:

1. Does it work?
2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

The flash demo is hilarious! The weird high-tension computer-generated narrator combined with the shaky pointer is comedy gold! I kept expecting it to go off the deep end and start explaining how to kill all humans.

http://www.yessoftware.com/download/files/flash/dc/AppBuilder_TaskManager.html

-sam

The glue between these can be CGI::FormBuilder (and its wrapper module, for example Catalyst::Plugin::FormBuilder for Catalyst).

However, this module knows nothing about databases, you have to describe the fields of your form in a YAML-like file. Also, your controler tends to end up with a lot of "was this form submitted? did it validate? then push it to DBIC" boilerplate code.

I believe it wouldn't be too hard to write a DRY wrapper around FormBuilder, though, because most of the required information can already be found in the OO-relational mapper.

Are there form modules in CPAN which can do "subform" (a la MS Access)? This combined with updatable view feature from database are basically the "core" of MS Access which makes developing apps like POS/order/invoicing/library/etc very easy. Most webapp framework that I glance do not have this feature.