• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Practical catalyst
 

Practical catalyst

on

  • 6,328 views

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.

Statistics

Views

Total Views
6,328
Views on SlideShare
6,328
Embed Views
0

Actions

Likes
1
Downloads
30
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as OpenOffice

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Practical catalyst Practical catalyst Presentation Transcript

    • Practical Catalyst An Introduction to a cutting edge Web Framework
    • In the beginning there was HTML <a href=”http://www.cnn.com”>CNN</a> And it was good. But it didn't change..
    • 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.
    • 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.
    • Progression of Perl Web Technique
      • Writing HTML directly.
      • Leonard Stein's CGI.pm
      • Templating systems
      • The MVC Pattern and Frameworks
        • CGI::Application
        • Jifty
        • Catalyst
    • Overall Trends
      • Encapsulation of function.
      • Separation of function.
      • Let computers do more.
      • Let programmers do more with less.
    • HTML techniques
      • <P>text, followed by tidy
        • Tidy can also convert formats
          • Html -> xhtml
          • Html -> xml
      • Demoroniser
        • Clean up Microsoft-only text elements.
      • Replacing tables as format elements with css
        • CSS – The Hidden Manual
        • The “A List Apart” web site.
    • 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.
    • Catalyst uses what's available
      • Configuration - YAML and/or Config::General
      • Environment – Module::Starter
      • Test Harness - Test::More
      • Class Mgmt/Business Logic – Moose
      • ORM – DBIx::Class
      • Views – Templates, JSON, Email
      • Plugins to Attach Functionality
      • NonCatalyst Code -> Catalyst::Model::Adapter
    • Learning Catalyst
      • There are good books and bad books
        • Even the bad books will teach you something.
        • None of the books are really for beginners.
      • Catalyst::Manual::Tutorial
        • You're not going to understand it; just do it.
      • #catalyst on IRC
      • Catalyst mailing list.
      • Perl Monks
    • Installing Catalyst
      • Apt-Get Linux distros – (Ubuntu, Debian, Knoppix) - just install it as the distro docs recommend.
      • Fedora – It's in the repository (older than apt-get)
      • “Definitive Guide to Catalyst” recommends vendor Perl plus local::lib plus per user CPAN install.
      • Or, install modern Perl in an alternate location and use alternate CPAN tree.
    • Starting a Project catalyst.pl ProjectName This creates a directory structure just off your home dir.
    • Model Controller “ The Cloud” Model View Model
    • 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' ); }
    • Controller Attributes
      • Global - URL same as method name
      • Local – URL = controller name + method name
      • Private – only accessible internally
      • Path – (Literal URL)
      • Arg – Only suck down this many arguments
      • Chain – I don't use these.
        • Useful for urls of the form:
          • http://store.com/location/500/item/233
    • What's that $c object?
      • $c is the context object
      • $c contains several important objects
        • $c->request or $c->req
        • $c->response or $c->res
        • $c->log
        • $c->stash
        • $c->session
    • 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
      • Take factored data and pass it to the right view.
    • Controller Data Stores
      • Stash: short term, lasts one response cycle. Data are references, same form as TT takes for its process() method.
      • Flash: longer term. Used often with the flash_to_stash config set. Useful for storage when handling forms.
      • 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.
    • Data – Long Term Storage
      • Usually handled with a database
        • But check out http://sedition.com/a/2794
        • The above shows how to read text files.
      • Build your tables, and then use the database to build the ORM schema.
      • script/nflanalyze_create.pl model DB DBIC::Schema NflAnalyze::Schema
      • create=static components=TimeStamp,EncodedColumn
      • 'dbi:Pg:dbname=DB_NAME' 'user' 'password' '{ AutoCommit => 1 }'
    • DBIx Created Models
      • Results
        • One result class per table.
        • These instantiate “has many”, “belongs to”, and “many to many” relationships.
        • Some databases better at this than others.
        • Use these for single results.
      • ResultSets
        • Create these modules (one per Result) to handle complex searches on each result
    • 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.
      • These return objects unless you export row hashes.
      • You might want to export row hashes if you're working with JSON views (broken with objects).
      • Consider letting the databases do your sorts here.
    • 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; }
    • “Metamodels”
      • Business code that sits between Schema and the controller, factoring data to look the way the View might want.
      • use parent 'Catalyst::Model';
      • use Moose;
      • use MyApp::Model::DB;
      • my $model = new MyApp::Model::DB;
      • $model->resultset('Table')->search('etc');
    • Models (General)
      • Build using Moose, develop in separate directory (or separate subdir from Cat app)
      • Use Catalayst::Model::Adaptor or Catalyst::Model::Factory to hook into Catalyst.
      • Advantage is the model can be tested and used outside of Catalyst (cmd line apps).
    • 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' ); };
    • 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->{$_} ); } }
    • 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' ); }
    • Catalyst and CGI::Formbuilder
      • CGI::Formbuilder: handles forms and allows javascript based authentication of input data.
      • Formbuilder allows you to use a YAML file to build a form.
      • Has its own web site:
      • Because of the transition of Cat to Moose, some changes to instantiation are required now.
    • Adding Formbuilder to Cat
      • Beginning changes for CGI::Formbuilder
        • BEGIN {extends 'Catalyst::Controller'; }
        • extends 'Catalyst::Controller::FormBuilder';
      • End Changes for CGI::Formbuilder
        • Comment out end immutable statement:
        • # __PACKAGE__->meta->make_immutable;
    • The Systems Administrator
      • Ties functionality together
      • Tends to use short, purposeful scripts
      • Often overloaded (working @ 110%)
      • Often being asked to automate tasks formerly done through sheer numbers.
      • Often asked to provide some functions, but not all, that would normally be handled by root.
    • Automation tools
      • Sudo
      • Scripts plus restricted shell logins.
      • Teaching power users to handle script libraries.
      • All the above require logins.
      • All the above tied to specific hardware.
      • This leads to the idea of using web interfaces as automation components
    • Web Automation
      • Plusses:
      • Better access control
      • Cross platform
      • More control over data presentation.
      • Creates a face to the organization.
      • Minuses:
      • Higher order skills required
      • Presentation code can suck up time
      • Languages (php) aren't compatible with scripting tools.
    • Catalyst as an automation tool
      • Language base the same as many scripts.
      • Lower barrier of entry
      • Relatively straightforward method to take code from scripts to web tools.
      • Resultant tools can be designed to be multipurpose, both web and command line enabled.
      • Catalyst methology supports code reuse.
    • From script to web tool
      • Write a useful script.
      • 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”
      • Export functionality to users.
      • Refactor as required.