Practical catalyst

7,255 views

Published on

Slides given as part of a talk for the Atlanta Perl Mongers, December 2, 2010.

Published in: Technology
  • Be the first to comment

Practical catalyst

  1. 1. Practical Catalyst An Introduction to a cutting edge Web Framework
  2. 2. In the beginning there was HTML <a href=”http://www.cnn.com”>CNN</a> And it was good. But it didn't change..
  3. 3. HTML was a response to the “ Tower of Babel” problem. Computers had trouble talking in ways that were independent of the operating systems and applications on which they were based. HTML and browsers were a way around that.
  4. 4. CGI – dynamic HTML With forms and content that users could interact with, the tools were built to give us things like ecommerce, web mail, etc.
  5. 5. Progression of Perl Web Technique <ul><li>Writing HTML directly.
  6. 6. Leonard Stein's CGI.pm
  7. 7. Templating systems
  8. 8. The MVC Pattern and Frameworks </li><ul><li>CGI::Application
  9. 9. Jifty
  10. 10. Catalyst </li></ul></ul>
  11. 11. Overall Trends <ul><li>Encapsulation of function.
  12. 12. Separation of function.
  13. 13. Let computers do more.
  14. 14. Let programmers do more with less. </li></ul>
  15. 15. HTML techniques <ul><li><P>text, followed by tidy </li><ul><li>Tidy can also convert formats </li><ul><li>Html -> xhtml
  16. 16. Html -> xml </li></ul></ul><li>Demoroniser </li><ul><li>Clean up Microsoft-only text elements. </li></ul><li>Replacing tables as format elements with css </li><ul><li>CSS – The Hidden Manual
  17. 17. The “A List Apart” web site. </li></ul></ul>
  18. 18. Catalyst <ul><li>Catalyst is a web framework. </li><ul><li>Derived from the Maypole framework. </li></ul><li>Things Catalyst is not: </li><ul><li>Catalyst is not lightweight </li><ul><li>There is a substantial software stack with Cat </li></ul><li>Catalyst does not boot quickly </li><ul><li>Optimized for persistent environments </li></ul><li>Catalyst does not force you to program in any specific way. </li></ul></ul>
  19. 19. Catalyst uses what's available <ul><li>Configuration - YAML and/or Config::General
  20. 20. Environment – Module::Starter
  21. 21. Test Harness - Test::More
  22. 22. Class Mgmt/Business Logic – Moose
  23. 23. ORM – DBIx::Class
  24. 24. Views – Templates, JSON, Email
  25. 25. Plugins to Attach Functionality
  26. 26. NonCatalyst Code -> Catalyst::Model::Adapter </li></ul>
  27. 27. Learning Catalyst <ul><li>There are good books and bad books </li><ul><li>Even the bad books will teach you something.
  28. 28. None of the books are really for beginners. </li></ul><li>Catalyst::Manual::Tutorial </li><ul><li>You're not going to understand it; just do it. </li></ul><li>#catalyst on IRC
  29. 29. Catalyst mailing list.
  30. 30. Perl Monks </li></ul>
  31. 31. Installing Catalyst <ul><li>Apt-Get Linux distros – (Ubuntu, Debian, Knoppix) - just install it as the distro docs recommend.
  32. 32. Fedora – It's in the repository (older than apt-get)
  33. 33. “Definitive Guide to Catalyst” recommends vendor Perl plus local::lib plus per user CPAN install.
  34. 34. Or, install modern Perl in an alternate location and use alternate CPAN tree. </li></ul>
  35. 35. Starting a Project catalyst.pl ProjectName This creates a directory structure just off your home dir.
  36. 36. Model Controller “ The Cloud” Model View Model
  37. 37. A Typical Controller Method sub intro : Local { my ( $self, $c ) = @_; my $params = $c->req->params; $c->stash( current_view => 'TT' ); $c->stash( template => 'draft/intro.tt' ); }
  38. 38. Controller Attributes <ul><li>Global - URL same as method name
  39. 39. Local – URL = controller name + method name
  40. 40. Private – only accessible internally
  41. 41. Path – (Literal URL)
  42. 42. Arg – Only suck down this many arguments
  43. 43. Chain – I don't use these. </li><ul><li>Useful for urls of the form: </li><ul><li>http://store.com/location/500/item/233 </li></ul></ul></ul>
  44. 44. What's that $c object? <ul><li>$c is the context object
  45. 45. $c contains several important objects </li><ul><li>$c->request or $c->req
  46. 46. $c->response or $c->res
  47. 47. $c->log
  48. 48. $c->stash
  49. 49. $c->session </li></ul></ul>
  50. 50. Controllers Formalized <ul><li>Check passing parms and POST params </li><ul><li>GETs end up in passing parms </li><ul><li>my ($self, $c, $get1, $get2, $get3 ) = @_; </li></ul><li>POSTs </li><ul><li>my $params = $c->req-params; </li></ul></ul><li>Get data from and pass data to models
  51. 51. Take factored data and pass it to the right view. </li></ul>
  52. 52. Controller Data Stores <ul><li>Stash: short term, lasts one response cycle. Data are references, same form as TT takes for its process() method.
  53. 53. Flash: longer term. Used often with the flash_to_stash config set. Useful for storage when handling forms.
  54. 54. Session: lasts some time. Can last longer than visitor's login, 2 hrs by default. Don't use same data names as stash, because they interact. </li></ul>
  55. 55. Data – Long Term Storage <ul><li>Usually handled with a database </li><ul><li>But check out http://sedition.com/a/2794
  56. 56. The above shows how to read text files. </li></ul><li>Build your tables, and then use the database to build the ORM schema.
  57. 57. script/nflanalyze_create.pl model DB DBIC::Schema NflAnalyze::Schema
  58. 58. create=static components=TimeStamp,EncodedColumn
  59. 59. 'dbi:Pg:dbname=DB_NAME' 'user' 'password' '{ AutoCommit => 1 }' </li></ul>
  60. 60. DBIx Created Models <ul><li>Results </li><ul><li>One result class per table.
  61. 61. These instantiate “has many”, “belongs to”, and “many to many” relationships.
  62. 62. Some databases better at this than others.
  63. 63. Use these for single results. </li></ul><li>ResultSets </li><ul><li>Create these modules (one per Result) to handle complex searches on each result </li></ul></ul>
  64. 64. More on ResultSets <ul><li>These are likely to be the first modules that you start putting business logic into after you start writing – resist the urge.
  65. 65. These return objects unless you export row hashes.
  66. 66. You might want to export row hashes if you're working with JSON views (broken with objects).
  67. 67. Consider letting the databases do your sorts here. </li></ul>
  68. 68. ResultSet returning AoH sub position_array { my ( $self, $sport_id ) = @_; my @rows = $self->search( sport_id => $sport_id, { order_by => { -asc => 'id'}} ); my @positions; for (@rows) { my %row = $_->get_columns; push @positions, %row; } return @positions; }
  69. 69. “Metamodels” <ul><li>Business code that sits between Schema and the controller, factoring data to look the way the View might want.
  70. 70. use parent 'Catalyst::Model';
  71. 71. use Moose;
  72. 72. use MyApp::Model::DB;
  73. 73. my $model = new MyApp::Model::DB;
  74. 74. $model->resultset('Table')->search('etc'); </li></ul>
  75. 75. Models (General) <ul><li>Build using Moose, develop in separate directory (or separate subdir from Cat app)
  76. 76. Use Catalayst::Model::Adaptor or Catalyst::Model::Factory to hook into Catalyst.
  77. 77. Advantage is the model can be tested and used outside of Catalyst (cmd line apps). </li></ul>
  78. 78. Typical Ajax request via jQuery function savesession() { clearstatus(); clearerror(); var lhcoll=$(&quot;#sortable&quot;).sortable(&quot;serialize&quot;); var rhcoll=$(&quot;#sortable2&quot;).sortable(&quot;serialize&quot;); var data = {}; data.ajax = 1; data.savesession = 1; data.lhcoll = lhcoll; data.rhcoll = rhcoll; jQuery.post(&quot;[% c.uri_for( c.controller.action_for('topplayer')) -%]&quot;, data, function ( hash ) { addstatus( hash.status_msg ); }, 'json' ); };
  79. 79. Catalyst Ajax dispatching my %tp_dispatch = ( savesession => 'do_save_tpl', clearsession => 'do_clear_tpl', save_db_session => 'do_save_db_tpl', load_db_session => 'do_load_db_tpl', ); # code code code if ( $params->{ajax} ) { for ( keys %tp_dispatch ) { $c->forward( $tp_dispatch{$_} ) if ( $params->{$_} ); } }
  80. 80. Output to a view (composite) if ( $params->{ajax} ) { $c->stash( current_view => 'JSON' ); } else { $c->stash( lh => $lists->{lh} ); $c->stash( rh => $lists->{rh} ); $c->stash( current_view => 'TT' ); $c->stash( template => 'draft/topplayer.tt' ); }
  81. 81. Catalyst and CGI::Formbuilder <ul><li>CGI::Formbuilder: handles forms and allows javascript based authentication of input data.
  82. 82. Formbuilder allows you to use a YAML file to build a form.
  83. 83. Has its own web site:
  84. 84. Because of the transition of Cat to Moose, some changes to instantiation are required now. </li></ul>
  85. 85. Adding Formbuilder to Cat <ul><li>Beginning changes for CGI::Formbuilder </li><ul><li>BEGIN {extends 'Catalyst::Controller'; }
  86. 86. extends 'Catalyst::Controller::FormBuilder'; </li></ul><li>End Changes for CGI::Formbuilder </li><ul><li>Comment out end immutable statement:
  87. 87. # __PACKAGE__->meta->make_immutable; </li></ul></ul>
  88. 88. The Systems Administrator <ul><li>Ties functionality together
  89. 89. Tends to use short, purposeful scripts
  90. 90. Often overloaded (working @ 110%)
  91. 91. Often being asked to automate tasks formerly done through sheer numbers.
  92. 92. Often asked to provide some functions, but not all, that would normally be handled by root. </li></ul>
  93. 93. Automation tools <ul><li>Sudo
  94. 94. Scripts plus restricted shell logins.
  95. 95. Teaching power users to handle script libraries.
  96. 96. All the above require logins.
  97. 97. All the above tied to specific hardware.
  98. 98. This leads to the idea of using web interfaces as automation components </li></ul>
  99. 99. Web Automation <ul><li>Plusses:
  100. 100. Better access control
  101. 101. Cross platform
  102. 102. More control over data presentation.
  103. 103. Creates a face to the organization. </li></ul><ul><li>Minuses:
  104. 104. Higher order skills required
  105. 105. Presentation code can suck up time
  106. 106. Languages (php) aren't compatible with scripting tools. </li></ul>
  107. 107. Catalyst as an automation tool <ul><li>Language base the same as many scripts.
  108. 108. Lower barrier of entry
  109. 109. Relatively straightforward method to take code from scripts to web tools.
  110. 110. Resultant tools can be designed to be multipurpose, both web and command line enabled.
  111. 111. Catalyst methology supports code reuse. </li></ul>
  112. 112. From script to web tool <ul><li>Write a useful script.
  113. 113. Separate logic from i/o (“Moosize” code) </li><ul><li>Doesn't require expert oo. Bag of methods classes enough at this stage. </li></ul><li>Drop Moose module into Catalyst “docking station”
  114. 114. Export functionality to users.
  115. 115. Refactor as required. </li></ul>

×