Your SlideShare is downloading. ×
Practical catalyst
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Practical catalyst

6,726
views

Published on

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

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

Published in: Technology

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
6,726
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
32
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

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

×