Catalyst - refactor & have fun

– refactor large apps with tE@M (of individuals)

and have fun!

Adam Bartosik, krakow.pm

365What we had?

24 Existing datawarehouse with CGI web interface working (mostly) 24h*365 build by many people Perl supports individuality Large projects HATE this

What we had?

Codebase: different styles of programming / how perl was growing in-line script / eval { main() } / procedural split into packages

3 approaches to html templates 3 database wrappers own date-time counting libs hacks, hacks, hacks.../ bugs, bugs, bugs...

What we had / we want

perl is not too formal a language. Great for things you need to change,develop the way you've never thought before /what we mostly do/.

The bigger a perl project is, the more rules you need to obey.

warnings, strict, perl-critic are just about code quality, not about design practices

XP, test-approach, test-suits - hard to start but make work easier, safer and faster (changes are welcome!)

What we want?

make it the best possible way make it easier maintainable learn something new, have fun :)

Choosing new platform

hours of talking, advocating use CPAN instead of self-made libs (opposit to

company politic?) they have better doc better tested are still being developed eg. DateTime is slower than simple $date, but

checks ranges SQL::Abstract can quote everything TT can move view-logic to templates

web framework needed!

we don't like to deal with sessions, url handling, redirecting (handling simple redirect in cgi is NOT simple)

CGI::App is like glue, but we need fundaments it should be popular enough to have some

support level /work must be done/ so the winner is...

Catalyst ++

Catalyst – similar to Rails MVC – code / layout / data source

MUST (/should) be split :) directory layout can start web app in a minute most of web tasks (sessions, url mapping,

redirects) are one-liners self server to test changes (quick start for

developers)

Catalyst --

hard to find good doc (but going better) too flexible, TIMTOWTDI

what to use for O/R mapping? which templates? type of config file? session storage? view type?

Rails, Django are easier to start with, have better doc, marketing, hype, ”proper way to do it”

?Learning curve

start-up: first 2-3 weeks are the worst tutos, docs, advent calendars, Handel, different

approaches, different results logical or a crap we wasting time on?

Learning curve

Template Toolkit make life easier: pass complex data [ {name=>bar}, {name=>baz} ]

to templates, iterations are done in tpl <ul> [% FOREACH row IN rows %]

<li>[% row.name %][% END %] </ul>

easy Ajax integration can switch totally different layouts (we needed it 3

months later – nice to be possible do this without big hacks)

Don't forget Mason => no another lang in tpl

DBIx::Class – rapid ORM interface use when it is worth to use it is not trivial to rewrite complex SQL queries to

dbix, does not simplify complicated joins (we have datawarehouse, a little more than blog – SQL can be simpler)

dbix is powerfull for data updating $post = $c->model('app::comment')->create({

nick => $c->req->{'nick'}, value => $c->req->{'value'} });$post->update;

Learning curve

Easy ”hard CGI things” dynamic redirect (after save, redirect user to eg.

main page)

sub save : Local { my ($self, $c) = @_; # save # redirect $c->res->redirect($c->uri_for('/'));}

Learning curve

Global ”catch-flag”, eg: change language choose output format

app/Controller/Root.pm

sub pdf : Regex('\.?pdf$') { my ($self, $c) = @_; my $redir = $c->req->path; $redir =~ s/\.pdf$//; $c->stash->{output_pdf} = 1; $redirect =~ s{/$}{/index}; $c->forward($redirect);}

Learning curve

Preserve link layout (when SEO matters)

URL: /news/what-about-perl6.html

sub news : LocalRegex('^/(.+)\.html$') { my ($self, $c) = @_; my $title = $c->req->captures->[0]; # find this article by $title...}

Learning curve

Still no best answer to all form/multiform/validation tasks. HTML::Widget Form::Builder everything is possible, but typically breaks mvc

MVC: Forms design should be in templates (view, css, layout), not in controllers, validation rules for input data should be placed in models (see Rails approach)

Learning curve

Web-services – SOAP, XML-RPC, REST – to share data with other systems/projects just output xml/yaml/anything

sub xml : Local { $c->res->body(XMLout($data)); # kiss/works}

build simple controller with pure TT and xml template (fast when you must pass defined output, DTD/Schema)

many plugins/controllers in CPAN, eg. C::P::Flavour, see also Catalyst Cookbook / simply ask what kind of abstraction for WS you need

Learning curve

Catalyst is social!

easy to work together – code is split /by design/ into many parts

no global switches/routing rules => less conflicts in code repository

the team can scale: start with 2, growth to 5 or more

We must obey some rules & conventions – what, where, how – work in team need some rules => they make life easier

why develop own libs when there are so many good on CPAN? We can fix bugs, extend them, contribute to open source less own codebase => lower costs more developers => better approaches other features => can need them in 2 or 3 months

Catalyst is social!

Months of active developemt but codebase is still fresh (and it is perl, true!) Clear design Only ”business application” code Less to type

We can make deep changes: multi-level caches for balanced nodes

with pre-caching change layout as often as is needed by marketing :)

Benefits after time

Catalyst works like a web-processing meta-language

It is not that (dirty) perl, it is a Catalyst

Benefits after time

see in Krakow!

Thanks - krakow perl mongers