Catalyst - refactor & have fun
– refactor large apps
with tE@M (of individuals)
and have fun!
Adam Bartosik, krakow.pm

What we had?
24
Existing datawarehouse with CGI web interface

365
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


Learning curve
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

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

Catalyst is social!
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


Benefits after time
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


see in Krakow!
Thanks - krakow perl mongers