[Catalyst] Mason + DBI + Catalyst?

[Joe Landman]

Daniel Carrera wrote:
> Andrew Rodland wrote:
>> The info you need on how things get glued together is in perldoc 
>> Catalyst::View::Mason and perldoc Catalyst::Model::DBI.
> 
> I didn't know about Catalyst::View::Mason, thanks. Btw, this is related 
> to the point of my post, it is hard to RTFM if you don't know where the 
> FM is. Or rather, the FM I knew of was about TT rather than Mason.

We use Mason rather than TT for our Catalyst apps (most of our web-apps 
which aren't CGI based).  We use Mason mostly for templating, using 
subcomponents to handle common features.  This works very well.

The beauty of Catalyst is that it doesn't impose a particular view (pun 
intended) upon you.  Nor for that matter, does it impose a particular 
model.  More in a moment.

>> And incidentally, you're wrong about DBIC. As soon as you get into 
>> queries for related tables, DBIC will be reducing the amount of code 
>> you need to write (and the number of potential screwups) tenfold.
> 
> I hesitate to make predictions like this. I don't know DBIC, and you 
> don't know my queries. I know that I find SQL no harder than Perl, and 
> that I appreciate being able to experiment with queries with phpMyAdmin. 

I am not a huge fan of DBIC myself.  But I don't like SQL all that much. 
  I do prefer something else to generate correct SQL.  Happily, most of 
my  SQL tends to be quite simple.  But I still like something in there 
to handle this for me.

This is where Catalyst really shines.  I don't *need* to use the "M" 
portion of the MVC.  I can use my own code (which I often do) rather 
than using the integrated Model capabilities, which are overkill for our 
apps.

When I need to use the M portion, I find Catalyst::Model::Jifty::DBI 
matches my thought processes better than DBIC.  This isn't a criticism 
of DBIC.  Just a personal prefernce.

Most of the examples assume DBIC though, so you have to (often) 
transliterate if you are using something else.

> So I can't help but wonder if it really makes sense to use a Perl module 
> to write the SQL for me rather than write the SQL directly. How would 
> you tell DBIC to use a sub query or to use a temporary table? Is it hard?

DBIC is very powerful.  I believe it has the capabilities you wish for.

The only thing I do wish for is a simpler login capability.  We have 
authentication and authorization controllers.  We have many different 
things to admix together.  What I would like at some point, is a simple 
controller that points to a DB or other data source, a login page 
template that must provide several fields, and can optionally supply 
others.  As far as I am aware, this doesn't exist today, and I find with 
the rapid rate of change of the core, a login controller I wrote 2 years 
ago, doesn't always work with the newer code.  Which is a problem.

Things like that would be quite helpful, for those of us who don't want 
to spend our time writing login/logout controllers, but want to focus 
upon writing our apps.

I could be wrong, but I don't think it does exist.

Joe

-- 
Joseph Landman, Ph.D
Founder and CEO
Scalable Informatics LLC,
email: landman at scalableinformatics.com
web  : http://www.scalableinformatics.com
        http://jackrabbit.scalableinformatics.com
phone: +1 734 786 8423 x121
fax  : +1 866 888 3112
cell : +1 734 612 4615