[Catalyst-commits] r14185 - in
trunk/examples/CatalystAdvent/root/2011: . pen
dhoss at dev.catalyst.perl.org
dhoss at dev.catalyst.perl.org
Tue Dec 6 09:21:46 GMT 2011
Author: dhoss
Date: 2011-12-06 09:21:46 +0000 (Tue, 06 Dec 2011)
New Revision: 14185
Added:
trunk/examples/CatalystAdvent/root/2011/3.pod
trunk/examples/CatalystAdvent/root/2011/4.pod
Removed:
trunk/examples/CatalystAdvent/root/2011/pen/dpetrov_local_lib_cpanm.pod
trunk/examples/CatalystAdvent/root/2011/pen/lecstor_fat_model.pod
Log:
publish. idgaf.
Copied: trunk/examples/CatalystAdvent/root/2011/3.pod (from rev 14184, trunk/examples/CatalystAdvent/root/2011/pen/lecstor_fat_model.pod)
===================================================================
--- trunk/examples/CatalystAdvent/root/2011/3.pod (rev 0)
+++ trunk/examples/CatalystAdvent/root/2011/3.pod 2011-12-06 09:21:46 UTC (rev 14185)
@@ -0,0 +1,103 @@
+=head1 Get fat this Christmas
+
+This Christmas do yourself a favour and get fat! with a fat model! what could be sweeter?
+
+Of course we're talking about a Catalyst Model as in Model, View, Controller. When I started using Catalyst and eventually got my head around all the parts and where they all fit in, the slot for my "business logic" seemed to be in the Controllers and I think that's a common assumption.
+
+The first thing that got my spidey sense tingling about this approach was when I realised I had multiple Actions with the same code. I'm very, very DRY so that bugged me a lot. Because I was in a Controller my first attempts at fixing this resulted in lots of forwarding between Actions both private and not.. this gets very messy, very quickly.
+
+Ok, so why not regular methods in the Controllers which are called from your Actions? This is a better solution wherever possible but I must admit it makes me feel icky.. a Controller is a place for Actions and for clarity, modularity, etc, I prefer to keep everything else out..
+
+To this end I looked to the model, the next (first?) obvious place to put these common methods. At this stage I was still trying to fit my code into Catalyst and made a couple of attempts at small Models for targeted functionality but then ran into issues from wanting access from one Model to another. At the same time I also discovered the issues involved in accessing Catalyst code from cron scripts and the like..
+
+ok, finally, my current solution? the fat Model. Essentially it's your whole app wrapped up in it's own nice "little" module..
+
+=head2 My App
+
+ package My::App;
+ use Moose;
+
+ has 'config' => ( isa => 'My::App::Config', is => 'ro', required => 1 );
+
+ has 'schema' => ( isa => 'DBIx::Class::Schema', is => 'ro', required => 1 );
+
+ has 'template' => ( isa => 'Template', is => 'ro' );
+
+ has 'visitor' => ( isa => 'My::App::Visitor', is => 'ro' );
+
+ has 'products' => ( isa => 'My::App::Products', is => 'ro', lazy_build => 1 );
+
+ sub _build_products{
+ My::App::Products->new({ schema => $_[0]->schema });
+ }
+
+With this as an entry point I can easily write a script which uses this class to access the full functionality of my app. I've also skipped a lot of coercing and auto-building in this example which you can use to make things even simpler.
+
+ok, but I thought we were talking about Models?
+
+=head2 My App Model
+
+ package My::Catalyst::Model::MyApp;
+ use Moose;
+ extends 'Catalyst::Model::Factory::PerRequest';
+
+ __PACKAGE__->config( class => 'My::App' );
+
+ # Instantiate the main app for each request.
+ sub prepare_arguments {
+ my ($self, $c) = @_;
+
+ my $args = $c->config->{'Model::MyApp'}{args};
+
+ $args->{template} = $c->view('TT')->template;
+ $args->{schema} = $c->model('DB')->schema;
+
+ $c->session unless $c->sessionid;
+
+ my $visitor = { session_id => $c->sessionid };
+ $visitor->{user} = $c->user if $c->user_exists;
+
+ $args->{visitor} = My::App::Visitor->new($visitor);
+
+ return $args;
+ }
+
+ no Moose;
+ __PACKAGE__->meta->make_immutable();
+
+ 1;
+
+With this model in my Catalyst app I can now access my main app from wherever I need within the Catalsyt system via $c->model('MyApp'). I'm also reusing things that Catalyst makes simple like my database model and template object. I use the template object when creating system emails in my app and there's no reason to instantiate a new Template object each time, and I can set it up once and know the same instance will be used everywhere.
+
+=head2 My Controller
+
+ package My::Catalyst::Controller::Root;
+ use Moose;
+ use namespace::autoclean;
+
+ BEGIN { extends 'Catalyst::Controller' }
+
+ __PACKAGE__->config(namespace => '');
+
+ sub index : Local{
+ my ( $self, $c ) = @_;
+
+ my $app = $c->model('MyApp');
+
+ $c->stash({
+ template => 'index.tt',
+ latest_products => $app->products->latest
+ });
+ }
+
+Now I can use Catalyst for all the wonderful things it makes so easy while keeping my main app nicely separated from it. Oh, and just quietly.. if the sky turned green and I needed to set up a quick Dancer or Mojolicious app I could do that quite easily too..
+
+have a great Christmas and an excellent New Year.. then we'll start all over agin..
+
+cheers,
+
+-- J
+
+=head1 AUTHOR
+
+Jason Galea <jason at lecstor.com>
Copied: trunk/examples/CatalystAdvent/root/2011/4.pod (from rev 14184, trunk/examples/CatalystAdvent/root/2011/pen/dpetrov_local_lib_cpanm.pod)
===================================================================
--- trunk/examples/CatalystAdvent/root/2011/4.pod (rev 0)
+++ trunk/examples/CatalystAdvent/root/2011/4.pod 2011-12-06 09:21:46 UTC (rev 14185)
@@ -0,0 +1,95 @@
+=head1 Keep your libraries organized
+
+In this article we'll discuss how to organize your libraries and following the
+best practices these days to avoid installing new cpan modules as root. This
+way you can always test your applications and experiment with the latest
+versions of some modules without being afraid that you can screw something.
+
+=head2 Installing cpanminus and local::lib
+
+Before we start, we should say a few words about cpanminus and local::lib.
+L<cpanminus|App::cpanminus> is a great script to get, unpack, build and
+install modules from CPAN and L<local::lib> is a greet tool to create and use
+local lib/ for perl modules.
+
+Installing modules locally has never been easier.
+First we need to install App::cpanminus and local::lib locally:
+
+ curl -L http://cpanmin.us | perl - -l ~/perl5 App::cpanminus local::lib
+
+This will install either cpanminus and local::lib (and all other required
+modules) locally into $HOME/perl5 directory.
+
+Now all we need to do is now to specify the appropriate environment variables
+to tell Perl where to look for installed modules.
+
+ eval `perl -I ~/perl5/lib/perl5 -Mlocal::lib=~/perl5`
+ echo 'eval $(perl -I$HOME/perl5/lib/perl5 -Mlocal::lib)' >> ~/.bashrc
+
+It's time to install Catalyst locally:
+
+ dpetrov at vaio:~$ cpanm Catalyst Catalyst::Devel
+
+=head2 perlbrew
+
+L<perlbrew|App::perlbrew> is incredible easy to use Perl Environment manager
+which lets you to manage different Perl installations in your $HOME. This
+could be useful if you don't want to upgrade your system Perl or you would
+like to test your code behavior under different Perl versions.
+
+Assuming that you've already installed cpanminus let's brew some of the latest
+Perl versions.
+
+First we need to insall App::perlbrew:
+
+ dpetrov at vaio:~$ cpanm App::perlbrew
+ --> Working on App::perlbrew
+ ...
+ Successfully installed App-perlbrew-0.33
+ 28 distributions installed
+
+Than we need to init perlbrew:
+
+ dpetrov at vaio:~$ perlbrew init
+ ...
+ Enjoy perlbrew at $HOME!!
+
+We can take a look to all available Perl versions:
+
+ dpetrov at vaio:~$ perlbrew available
+ perl-5.15.5
+ perl-5.14.2
+ ...
+
+And finally we can brew the some of the latest available Perl versions.
+
+ dpetrov at vaio:~$ perlbrew install 5.14.2
+ ...
+
+Since that could take a while you can probably go and grab a cup of coffee :)
+Once the new Perl version is installed we can switch and verify that:
+
+ dpetrov at vaio:~$ perlbrew use perl-5.14.2
+ A sub-shell is launched with perl-5.14.2 as the activated perl. Run 'exit'
+ to finish it.
+
+ dpetrov at vaio:~$ perl -v
+ This is perl 5, version 14, subversion 2 (v5.14.2) built for x86_64-linux
+
+Now you can enjoy using perl 5.14.2 and you can switch back to the system Perl
+version simply by turning C<perlbrew off>.
+
+=head2 NOTE
+
+We should mention that L<local::lib> was not designed to work with multiple
+Perl versions. That's so because usually XS modules are not compatible
+across major Perl releases. That's usually not such a big issue, because
+using L<perlbrew|App::perlbrew> you have your own Perl, which allows you to
+install different module versions across different Perl versions (and all
+that is locally).
+
+=head2 Summary
+
+=head1 AUTHOR
+
+Dimitar Petrov <mitakaa at gmail.com>
Deleted: trunk/examples/CatalystAdvent/root/2011/pen/dpetrov_local_lib_cpanm.pod
===================================================================
--- trunk/examples/CatalystAdvent/root/2011/pen/dpetrov_local_lib_cpanm.pod 2011-12-06 08:45:04 UTC (rev 14184)
+++ trunk/examples/CatalystAdvent/root/2011/pen/dpetrov_local_lib_cpanm.pod 2011-12-06 09:21:46 UTC (rev 14185)
@@ -1,95 +0,0 @@
-=head1 Keep your libraries organized
-
-In this article we'll discuss how to organize your libraries and following the
-best practices these days to avoid installing new cpan modules as root. This
-way you can always test your applications and experiment with the latest
-versions of some modules without being afraid that you can screw something.
-
-=head2 Installing cpanminus and local::lib
-
-Before we start, we should say a few words about cpanminus and local::lib.
-L<cpanminus|App::cpanminus> is a great script to get, unpack, build and
-install modules from CPAN and L<local::lib> is a greet tool to create and use
-local lib/ for perl modules.
-
-Installing modules locally has never been easier.
-First we need to install App::cpanminus and local::lib locally:
-
- curl -L http://cpanmin.us | perl - -l ~/perl5 App::cpanminus local::lib
-
-This will install either cpanminus and local::lib (and all other required
-modules) locally into $HOME/perl5 directory.
-
-Now all we need to do is now to specify the appropriate environment variables
-to tell Perl where to look for installed modules.
-
- eval `perl -I ~/perl5/lib/perl5 -Mlocal::lib=~/perl5`
- echo 'eval $(perl -I$HOME/perl5/lib/perl5 -Mlocal::lib)' >> ~/.bashrc
-
-It's time to install Catalyst locally:
-
- dpetrov at vaio:~$ cpanm Catalyst Catalyst::Devel
-
-=head2 perlbrew
-
-L<perlbrew|App::perlbrew> is incredible easy to use Perl Environment manager
-which lets you to manage different Perl installations in your $HOME. This
-could be useful if you don't want to upgrade your system Perl or you would
-like to test your code behavior under different Perl versions.
-
-Assuming that you've already installed cpanminus let's brew some of the latest
-Perl versions.
-
-First we need to insall App::perlbrew:
-
- dpetrov at vaio:~$ cpanm App::perlbrew
- --> Working on App::perlbrew
- ...
- Successfully installed App-perlbrew-0.33
- 28 distributions installed
-
-Than we need to init perlbrew:
-
- dpetrov at vaio:~$ perlbrew init
- ...
- Enjoy perlbrew at $HOME!!
-
-We can take a look to all available Perl versions:
-
- dpetrov at vaio:~$ perlbrew available
- perl-5.15.5
- perl-5.14.2
- ...
-
-And finally we can brew the some of the latest available Perl versions.
-
- dpetrov at vaio:~$ perlbrew install 5.14.2
- ...
-
-Since that could take a while you can probably go and grab a cup of coffee :)
-Once the new Perl version is installed we can switch and verify that:
-
- dpetrov at vaio:~$ perlbrew use perl-5.14.2
- A sub-shell is launched with perl-5.14.2 as the activated perl. Run 'exit'
- to finish it.
-
- dpetrov at vaio:~$ perl -v
- This is perl 5, version 14, subversion 2 (v5.14.2) built for x86_64-linux
-
-Now you can enjoy using perl 5.14.2 and you can switch back to the system Perl
-version simply by turning C<perlbrew off>.
-
-=head2 NOTE
-
-We should mention that L<local::lib> was not designed to work with multiple
-Perl versions. That's so because usually XS modules are not compatible
-across major Perl releases. That's usually not such a big issue, because
-using L<perlbrew|App::perlbrew> you have your own Perl, which allows you to
-install different module versions across different Perl versions (and all
-that is locally).
-
-=head2 Summary
-
-=head1 AUTHOR
-
-Dimitar Petrov <mitakaa at gmail.com>
Deleted: trunk/examples/CatalystAdvent/root/2011/pen/lecstor_fat_model.pod
===================================================================
--- trunk/examples/CatalystAdvent/root/2011/pen/lecstor_fat_model.pod 2011-12-06 08:45:04 UTC (rev 14184)
+++ trunk/examples/CatalystAdvent/root/2011/pen/lecstor_fat_model.pod 2011-12-06 09:21:46 UTC (rev 14185)
@@ -1,103 +0,0 @@
-=head1 Get fat this Christmas
-
-This Christmas do yourself a favour and get fat! with a fat model! what could be sweeter?
-
-Of course we're talking about a Catalyst Model as in Model, View, Controller. When I started using Catalyst and eventually got my head around all the parts and where they all fit in, the slot for my "business logic" seemed to be in the Controllers and I think that's a common assumption.
-
-The first thing that got my spidey sense tingling about this approach was when I realised I had multiple Actions with the same code. I'm very, very DRY so that bugged me a lot. Because I was in a Controller my first attempts at fixing this resulted in lots of forwarding between Actions both private and not.. this gets very messy, very quickly.
-
-Ok, so why not regular methods in the Controllers which are called from your Actions? This is a better solution wherever possible but I must admit it makes me feel icky.. a Controller is a place for Actions and for clarity, modularity, etc, I prefer to keep everything else out..
-
-To this end I looked to the model, the next (first?) obvious place to put these common methods. At this stage I was still trying to fit my code into Catalyst and made a couple of attempts at small Models for targeted functionality but then ran into issues from wanting access from one Model to another. At the same time I also discovered the issues involved in accessing Catalyst code from cron scripts and the like..
-
-ok, finally, my current solution? the fat Model. Essentially it's your whole app wrapped up in it's own nice "little" module..
-
-=head2 My App
-
- package My::App;
- use Moose;
-
- has 'config' => ( isa => 'My::App::Config', is => 'ro', required => 1 );
-
- has 'schema' => ( isa => 'DBIx::Class::Schema', is => 'ro', required => 1 );
-
- has 'template' => ( isa => 'Template', is => 'ro' );
-
- has 'visitor' => ( isa => 'My::App::Visitor', is => 'ro' );
-
- has 'products' => ( isa => 'My::App::Products', is => 'ro', lazy_build => 1 );
-
- sub _build_products{
- My::App::Products->new({ schema => $_[0]->schema });
- }
-
-With this as an entry point I can easily write a script which uses this class to access the full functionality of my app. I've also skipped a lot of coercing and auto-building in this example which you can use to make things even simpler.
-
-ok, but I thought we were talking about Models?
-
-=head2 My App Model
-
- package My::Catalyst::Model::MyApp;
- use Moose;
- extends 'Catalyst::Model::Factory::PerRequest';
-
- __PACKAGE__->config( class => 'My::App' );
-
- # Instantiate the main app for each request.
- sub prepare_arguments {
- my ($self, $c) = @_;
-
- my $args = $c->config->{'Model::MyApp'}{args};
-
- $args->{template} = $c->view('TT')->template;
- $args->{schema} = $c->model('DB')->schema;
-
- $c->session unless $c->sessionid;
-
- my $visitor = { session_id => $c->sessionid };
- $visitor->{user} = $c->user if $c->user_exists;
-
- $args->{visitor} = My::App::Visitor->new($visitor);
-
- return $args;
- }
-
- no Moose;
- __PACKAGE__->meta->make_immutable();
-
- 1;
-
-With this model in my Catalyst app I can now access my main app from wherever I need within the Catalsyt system via $c->model('MyApp'). I'm also reusing things that Catalyst makes simple like my database model and template object. I use the template object when creating system emails in my app and there's no reason to instantiate a new Template object each time, and I can set it up once and know the same instance will be used everywhere.
-
-=head2 My Controller
-
- package My::Catalyst::Controller::Root;
- use Moose;
- use namespace::autoclean;
-
- BEGIN { extends 'Catalyst::Controller' }
-
- __PACKAGE__->config(namespace => '');
-
- sub index : Local{
- my ( $self, $c ) = @_;
-
- my $app = $c->model('MyApp');
-
- $c->stash({
- template => 'index.tt',
- latest_products => $app->products->latest
- });
- }
-
-Now I can use Catalyst for all the wonderful things it makes so easy while keeping my main app nicely separated from it. Oh, and just quietly.. if the sky turned green and I needed to set up a quick Dancer or Mojolicious app I could do that quite easily too..
-
-have a great Christmas and an excellent New Year.. then we'll start all over agin..
-
-cheers,
-
--- J
-
-=head1 AUTHOR
-
-Jason Galea <jason at lecstor.com>
More information about the Catalyst-commits
mailing list