Re: [Catalyst] Mason + DBI + Catalyst?
On Wed, May 27, 2009 at 03:23:29PM +0300, Octavian Rasnita wrote: Ok, I will correct it (because I remember at least an error in it), test it and put it in a wiki. Can anyone recommend a good place for a thing like this? I'm not really very sure. How about a page linked off the 'faq' under a question of Why do you want me to use an ORM? ORMs are evil! or something? Not perfect but then it's there and somebody can move it later :) -- Matt S Trout Catalyst and DBIx::Class consultancy with a clue Technical Director and a commit bit: http://shadowcat.co.uk/catalyst/ Shadowcat Systems Limited mst (@) shadowcat.co.ukhttp://shadowcat.co.uk/blog/matt-s-trout/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Mason + DBI + Catalyst?
Octavian Râsnita ha scritto:
On Tue, May 26, 2009 at 01:37:40AM +0200, Daniel Carrera wrote:
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.
Here it is a short code example that might appear in a controller:
sub author : Local {
my ($self, $c) = @_;
#Variables you might get after the user submits a form:
my $name = $c-req-params-{name};
my $country = $c-req-params-{country};
#Search the database for all fiction authors:
my $authors = $c-model(DB::Authors)-search({
style = 'fiction',
});
#Until this point DBIC doesn't touch the database.
#Add filters based on what the user searched using the form:
$authors = $authors-search({name = {-like = %$name%}) if $name;
$authors = $authors-search({country = $country}) if $country;
#Until this point, DBIC also didn't touch the database.
#Add the $authors object to the stash, to be able to print it in a
template:
$c-stash-{authors} = $authors;
#Until here, DBIC didn't touch the database
}
#And the subroutine ended.
And then you can print some things using a Template-Toolkit template
(authors.tt):
[% IF some_variable = 1 %]
[% FOREACH author = authors.next %]
Name: [% author.name %]
Country: [% author.country %]
Localized birthday month: [%
author.birthday.set_locale('fr').month_name %]
The books of this author:
[% FOREACH book = author.books %]
[% book.title %] - [% book.editor %]
[% END %]
[% END %]
[% END %]
And at this point, DBIC still doesn't touch the database if the variable
some_variable is not equal to 1 so the code below the IF line
shouldn't be executed.
But if the variable is 1, only at this point DBIC executes the necessary
queries and get the data. And you have seen that due to the relations
that were created in the DBIC result classes, it would be very simple to
access not only data about the authors, but about his books or data that
can be found in other related tables, without needing to define a new
query.
I wrote this code in Outlook Express and it might have bugs because I
didn't test it, but I hope it helps to make an idea about what DBIC can do.
Octavian
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
I think this example is very interesting and should end up into the wiki
somewhere!
I think it can be a good selling point for DBIC, but I've not seen it
explained so well until now (but I admit I've not looked up the docs in
a while...)
Thank you.
--
Marcello Romani
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Mason + DBI + Catalyst?
From: Marcello Romani mrom...@ottotecnica.com Octavian Râsnita ha
scritto:
On Tue, May 26, 2009 at 01:37:40AM +0200, Daniel Carrera wrote:
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.
Here it is a short code example that might appear in a controller:
sub author : Local {
[snip]
I think this example is very interesting and should end up into the wiki
somewhere!
I think it can be a good selling point for DBIC, but I've not seen it
explained so well until now (but I admit I've not looked up the docs in a
while...)
Thank you.
--
Marcello Romani
Ok, I will correct it (because I remember at least an error in it), test it
and put it in a wiki.
Can anyone recommend a good place for a thing like this?
Octavian
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Mason + DBI + Catalyst?
On Tue, May 26, 2009 at 01:14:18AM +0200, Daniel Carrera wrote: 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. 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? If you can't make DBIC produce the exact SQL you would have written by hand, that's a missing feature in DBIC - at least so far as the development team is concerned. I often prototype queries by fiddling at the SQL level and then rewrite them into DBIC syntax afterwards - though equally as often I fire up a Devel::REPL re.pl and play around with resultsets with DBIC_TRACE on so it shows me the queries as it runs them. DBIx::Class -does- have a learning curve, but that's because it's an ORM written by people who actually like SQL and the relational model - so once you get to grips with it you should be able to write DBIC code and be able to see the SQL that's going to eventually be executed in your head, except be typing a lot less - and be able to use resultset chaining to put complex queries together in a piecemeal, reusable fashion. -- Matt S Trout Catalyst and DBIx::Class consultancy with a clue Technical Director and a commit bit: http://shadowcat.co.uk/catalyst/ Shadowcat Systems Limited mst (@) shadowcat.co.ukhttp://shadowcat.co.uk/blog/matt-s-trout/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Mason + DBI + Catalyst?
On Tue, May 26, 2009 at 01:37:40AM +0200, Daniel Carrera wrote:
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.
Have a look at -
http://www.shadowcat.co.uk/catalyst/-talks/yapc-na-2008/dbix-masterclass.xul
http://www.shadowcat.co.uk/archive/conference-video/yapc-eu-2008/dbic-masterclass/
http://xrl.us/oubg6
Those should give you an idea of the level of complexity that can be built
up elegantly.
Btw, why is it called DBIC if CPAN says DBIx::Class?
DBIx is the namespace for DBI extensions.
So we use DBIC as an abbreviation.
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.
-search just constructs another resultset.
DBIC doesn't hit the database until you make it via -count or -next/-all
(or something that calls one of those).
That's rather the key advantage of DBIC - a resultset is basically a sort of
lazy virtual view onto your database that turns itself into an SQL query as
and when (and only when) required to do so by something you want.
--
Matt S Trout Catalyst and DBIx::Class consultancy with a clue
Technical Director and a commit bit: http://shadowcat.co.uk/catalyst/
Shadowcat Systems Limited
mst (@) shadowcat.co.ukhttp://shadowcat.co.uk/blog/matt-s-trout/
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Mason + DBI + Catalyst?
On Tue, May 26, 2009 at 01:37:40AM +0200, Daniel Carrera wrote:
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.
Here it is a short code example that might appear in a controller:
sub author : Local {
my ($self, $c) = @_;
#Variables you might get after the user submits a form:
my $name = $c-req-params-{name};
my $country = $c-req-params-{country};
#Search the database for all fiction authors:
my $authors = $c-model(DB::Authors)-search({
style = 'fiction',
});
#Until this point DBIC doesn't touch the database.
#Add filters based on what the user searched using the form:
$authors = $authors-search({name = {-like = %$name%}) if $name;
$authors = $authors-search({country = $country}) if $country;
#Until this point, DBIC also didn't touch the database.
#Add the $authors object to the stash, to be able to print it in a template:
$c-stash-{authors} = $authors;
#Until here, DBIC didn't touch the database
}
#And the subroutine ended.
And then you can print some things using a Template-Toolkit template
(authors.tt):
[% IF some_variable = 1 %]
[% FOREACH author = authors.next %]
Name: [% author.name %]
Country: [% author.country %]
Localized birthday month: [% author.birthday.set_locale('fr').month_name
%]
The books of this author:
[% FOREACH book = author.books %]
[% book.title %] - [% book.editor %]
[% END %]
[% END %]
[% END %]
And at this point, DBIC still doesn't touch the database if the variable
some_variable is not equal to 1 so the code below the IF line shouldn't be
executed.
But if the variable is 1, only at this point DBIC executes the necessary
queries and get the data. And you have seen that due to the relations that
were created in the DBIC result classes, it would be very simple to access
not only data about the authors, but about his books or data that can be
found in other related tables, without needing to define a new query.
I wrote this code in Outlook Express and it might have bugs because I didn't
test it, but I hope it helps to make an idea about what DBIC can do.
Octavian
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
[Catalyst] Mason + DBI + Catalyst?
Hello, I'm starting to learn about Catalyst. I'm looking for a MVC framework for Perl. My first concern is that for views, Catalyst seems to be really geared toward TemplateToolkit and I don't really like TT. I think I like Mason (no real experience though). I know that Catalyst can work with Mason, but all the documentation talks about TT. And if a feature is not documented, as far as the user is concerned, it might as well not exist. Is there any good documentation for Catalyst that is based on Mason? I have a similar (but lesser) concern about the database module. Catalyst documentation seems to focus on DBIx::Class, but looking at DBIx I get the feeling that it just tries to hide SQL. This seems like a pointless exercise, since SQL is easy enough (and the Perl replacement is not easier). But more importantly, I worry about losing control. In my application I need to do moderately complex queries, like joining three tables, or using a temporary tables. Once again, I know that Catalyst is capable of using DBI, but if this is not well documented, it makes it that much harder for me to use Catalyst. And so far, the documentation seems to only talk about DBIx::Class. Any suggestions? Thanks. Daniel. ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Mason + DBI + Catalyst?
On Tue, May 26, 2009 at 12:35:45AM +0200, Daniel Carrera wrote: Is there any good documentation for Catalyst that is based on Mason? http://search.cpan.org/~flora/Catalyst-View-Mason-0.17/lib/Catalyst/View/Mason.pm Any suggestions? Nothing's stopping you from just using DBI. http://search.cpan.org/~alexp/Catalyst-Model-DBI-0.20/lib/Catalyst/Model/DBI.pm (I've never actually used this.) Anyway, the coupling between Catalyst, DBIC, and TT is loose, and it sounds like you're expecting a lot more opinionation from the framework than is actually there. (I'll leave it up to someone else to advocate for DBIC over plain DBI.) hdp. ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Mason + DBI + Catalyst?
On Monday 25 May 2009 05:35:45 pm Daniel Carrera wrote: Is there any good documentation for Catalyst that is based on Mason? Catalyst is Perl. Catalyst apps are Perl apps. All the docs you need on Mason are in perldoc Mason and all the docs you need on DBI are in perldoc DBI. The info you need on how things get glued together is in perldoc Catalyst::View::Mason and perldoc Catalyst::Model::DBI. 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. Then throw in bonus features like txn_do and the deployment goodies... it ends up being worthwhile pretty often ;) Andrew ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Mason + DBI + Catalyst?
On Mon, May 25, 2009 at 3:35 PM, Daniel Carrera
daniel.carr...@theingots.org wrote:
Hello,
I'm starting to learn about Catalyst. I'm looking for a MVC framework for
Perl. My first concern is that for views, Catalyst seems to be really geared
toward TemplateToolkit and I don't really like TT. I think I like Mason (no
real experience though). I know that Catalyst can work with Mason, but all
the documentation talks about TT. And if a feature is not documented, as far
as the user is concerned, it might as well not exist.
Is there any good documentation for Catalyst that is based on Mason?
I have a similar (but lesser) concern about the database module. Catalyst
documentation seems to focus on DBIx::Class, but looking at DBIx I get the
feeling that it just tries to hide SQL. This seems like a pointless
exercise, since SQL is easy enough (and the Perl replacement is not easier).
But more importantly, I worry about losing control. In my application I need
to do moderately complex queries, like joining three tables, or using a
temporary tables. Once again, I know that Catalyst is capable of using DBI,
but if this is not well documented, it makes it that much harder for me to
use Catalyst. And so far, the documentation seems to only talk about
DBIx::Class.
Any suggestions?
Thanks.
Daniel.
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive:
http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Hi Daniel,
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. However, if you
try to use Mason's framework system in conjunction with Catalyst, things
will get weird quickly.
Rather than Catalyst being geared towards TT, I would say Mason is geared
towards being a framework :)
The view should just be thin templates, in that regard I would recommend
using Catalyst::View::MicroMason (
http://search.cpan.org/~jrockway/Catalyst-View-MicroMason-0.05/lib/Catalyst/View/MicroMason.pm)
which wraps Text::MicroMason (Mason template syntax without the
framework).
There really isn't a lot of documentation, because nothing aside from the
path to the template is really related to Catalyst.
By default, your template rendered will be the action path name (in a
controller called Foo::Bar with an action called baz the template would
be root/foo/bar/baz.mc). This setup (which just sets
$c-stash-{template}) happens in Catalyst::Action::RenderView
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.
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.
I'll second hdp's opinion that you are expecting more from Catalyst.
Catalyst is glue, nothing more. If you want DBI, you can use
Catalyst::Model::DBI and get a $dbh object and put everything in your
controller and have a rather ugly application that isn't really MVC. But,
that's my opinion -- on a technical level it works fine.
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.
-J
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Mason + DBI + Catalyst?
On Mon, May 25, 2009 at 04:00:38PM -0700, J. Shirley wrote: The view should just be thin templates, in that regard I would recommend using Catalyst::View::MicroMason (http://search.cpan.org/~jrockway/Catalyst-View-MicroMason-0.05/lib/ Catalyst/View/MicroMason.pm) which wraps Text::MicroMason (Mason template syntax without the framework). Ew. If the OP is used to non-trivial Mason -- autohandlers, subcomponents, methods, etc., all things that are reasonable as part of a templating engine (i.e. not web framework-related) -- MicroMason isn't really going to be satisfactory. hdp. ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Mason + DBI + Catalyst?
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. 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. 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? Daniel. ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Mason + DBI + Catalyst?
On Mon, 25 May 2009, J. Shirley wrote: Rather than Catalyst being geared towards TT, I would say Mason is geared towards being a framework :) Well, sort of. Mason is quite usable as a pure templating system. I use Mason with Catalyst for all my new projects, and the framework parts of Mason really don't matter to me. The view should just be thin templates, in that regard I would recommend using Catalyst::View::MicroMason ( http://search.cpan.org/~jrockway/Catalyst-View-MicroMason-0.05/lib/Catalyst/View/MicroMason.pm) which wraps Text::MicroMason (Mason template syntax without the framework). Except you also lose really useful non-framework features like autohandlers, which are like TT's WRAPPER (but better, IMO). -dave /* http://VegGuide.org http://blog.urth.org Your guide to all that's veg House Absolute(ly Pointless) */ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Mason + DBI + Catalyst?
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: land...@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 ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Mason + DBI + Catalyst?
Hans Dieter Pearcey wrote: Ew. If the OP is used to non-trivial Mason -- autohandlers, subcomponents, methods, etc., all things that are reasonable as part of a templating engine (i.e. not web framework-related) -- MicroMason isn't really going to be satisfactory. Hmm... While I'm not used to anything about Mason in particular, I do expect certain features in a templating engine. If subcomonents refers to the ability to insert one component inside another, then that's a must-have feature. I can't imagine making an interesting website without that. Daniel. ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Mason + DBI + Catalyst?
On Mon, May 25, 2009 at 4:22 PM, Dave Rolsky auta...@urth.org wrote: On Mon, 25 May 2009, J. Shirley wrote: Rather than Catalyst being geared towards TT, I would say Mason is geared towards being a framework :) Well, sort of. Mason is quite usable as a pure templating system. I use Mason with Catalyst for all my new projects, and the framework parts of Mason really don't matter to me. Agreed, that's what I meant -- Mason has all the framework bits built in, which means a lot of Mason developers don't see the appeal of Catalyst (sadly). I think the best statement about Mason and Catalyst is that if you want to use View::Mason for the framework features, you are doing it wrong. Agreed? (I think Dave is safely the resident expert here on Mason so his opinion trumps certainly my own) Except you also lose really useful non-framework features like autohandlers, which are like TT's WRAPPER (but better, IMO). Of course that would be your opinion! ;) I actually thought MicroMason supported autohandlers (but not dhandlers) -- in that light, yes, just use Catalyst::View::Mason and disregard my recommendation. Sorry for the bad advice :) Flogging accepted by first person wielding sufficiently stiff bamboo rod. -J ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Mason + DBI + Catalyst?
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.
I mix-and-match using DBIC and plain DBI calls, but I do it by completely
abstracting the model layer from DBIC.
instead of using Catalyst::Model::DBIC::Schema, I just create a
MyApp::Model::Whatever (or the equivalent thereof), so the actual data
munging resides in the Whatever.pm, and the user doesn't know anything about
the underlying framework being used.
so my controllers do something like
sub foo :Local {
my ($self, $c) = @_;
my $data =
$c-model('Whatever')-load_data_using_really_complex_procedure();
# do what you will with data
}
Model::Whatever in turn just uses Catalyst::Model::Adaptor to delegate to a
Catalyst-agnostic thing, which handles the actual data munging
--d
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Mason + DBI + Catalyst?
On Tue, May 26, 2009 at 01:37:40AM +0200, Daniel Carrera wrote:
Btw, why is it called DBIC if CPAN says DBIx::Class?
For the same reason Mason isn't called HTML and Class::DBI isn't called
Class. The first part of a module's namespace is not necessarily how people
refer to it.
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.
That isn't what's happening; DBIC resultsets don't actually hit the database
until they need to, and incrementally building up conditions doesn't need to.
This isn't the right place to ask your questions or correct all your
misconceptions about DBIC. You really should see its mailing list or irc
channel (listed in the documentation).
hdp.
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Mason + DBI + Catalyst?
On Mon, May 25, 2009 at 6:36 PM, Hans Dieter Pearcey hdp.perl.catalyst.us...@weftsoar.net wrote: On Tue, May 26, 2009 at 01:37:40AM +0200, Daniel Carrera wrote: Btw, why is it called DBIC if CPAN says DBIx::Class? For the same reason Mason isn't called HTML and Class::DBI isn't called Class. The first part of a module's namespace is not necessarily how people refer to it. And just to clarify, DBIC just comes from DBI(x::)C(lass) So, DBIC or DBIx::Class. DBIx simply means Extension to DBI -- there are a number of DBIx:: modules that have nothing to do with DBIx::Class (but everything under DBIx::Class should have something to do with DBIC) Same with MooseX::Whatever -- it's a Moose eXtension (and not Moo Sex) -J ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
