[Catalyst] Mason + DBI + Catalyst?

[Daniel Carrera]

J. Shirley wrote:
> Catalyst is not geared towards TT, it is just that more Catalyst users 
> use TT so more documentation and articles are written centered around 
> TT.  The Mason view works just fine, and won't cause any problems.

Yeah. I probably didn't express myself well. It's an issue of 
documentation, rather than technology.

I wonder why people seem to prefer TT. I must be in the minority, but 
I'd prefer to use Perl in my templates rather than a different set of 
programming constructs (e.g. a different "FOREACH").


> The view should just be thin templates, in that regard I would recommend 
> using Catalyst::View::MicroMason ... (Mason template syntax without the 
> "framework").

Ah, thanks. This looks like the right thing for me. Thanks.

> Regarding DBIC (not DBIx, but that's a common naming mistake), your 
> concerns are certainly valid.  I'll address it sort of bullet-point 
> style, but if you want DBI then just use Catalyst::Model::DBI.  I would 
> recommend taking a day to play with DBIx::Class though, as it is quite nice.
> 
> DBIC and SQL::Abstract handle complex queries very well.  I have several 
> queries that span 8+ tables, with various join conditions.
> 
> You can have arbitrary SQL in a custom result source just fine.

Do you write your queries using straight SQL? For my application, MySQL 
is a bottleneck. So it is important to me that I have control over the 
queries to try to make them efficient. I don't have any query that spans 
8 tables though. So if you are happy with DBIC, then it should be good 
enough for me too. I'll take a second look at DBIC.

Btw, why is it called DBIC if CPAN says DBIx::Class?


> Being able to chain resultsets makes it much much easier than using 
> straight SQL, and you write less code.  If you have a query you've 
> constructed called $query, and lets say you now only want active records 
> you can do $query = $query->search({ active => 1 });  In this way you 
> can filter many things incrementally.

But is that efficient? It looks like you are getting MySQL to return the 
entire data set and then making Perl filter it. That can't be efficient.


> I'll second hdp's opinion that you are expecting more from Catalyst.  
> Catalyst is glue, nothing more.

Actually, that is precisely what got me interested in Catalyst. I don't 
like a lot of MVC frameworks (RoR, CakePHP) because they feel very 
restrictive.

I'm trying to find a difficult balance between doing MVC (so my code is 
clean, and well organized), and maintaining control (so I can fix a 
performance bottleneck, or make the app do something that's not common).


> A big reason you may not find the documentation you are looking for is 
> that glue is just a really simple tool.  It's all the other tools that 
> are hard to use.

Maybe. Maybe Catalyst just looks more complicated than it really is. I 
mean, there are a lot of pages of documentation. It felt a bit overwhelming.

Daniel.