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: [email protected]
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
_______________________________________________
List: [email protected]
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/[email protected]/
Dev site: http://dev.catalyst.perl.org/
