SweetPea / SweetPea::Application Pre-release Overview by Al Newkirk (awncorp)

Yet Another Web Application Framework

WHY? Frameworks are like religions, I could be Christian, you could be Muslim, or we both could be Christian, you Catholic and me Baptist.

Meaning What? One size does not fit all.

And Your Point Is? TIMTOWTDI (There is more than one way to do it) When given a choice, people are more likely to adopt frameworks (like religions) that converge with their existing concepts.

The SweetPea Concept A Perl web application framework that doesn't get in the way or suck.

Get In The Way? If the task is to create a web application using a framework to ease the tedium, but the framework over complicates the process, then that framework is in the way, and that sucks.

Define Over Complicate Web application frameworks that produce all or some of these issues are over complicating the initial goal (which is to create a web application): …

… complex, overly simple, loosely coupled, or incomplete API, inadequate documentation, steep learning curve, unscalable, missing core functionality, core functionality as plugins, complex syntax, inconsistent design concepts, and/or massive prerequisites irrelevant to the task.

The Solution Develop something truly scalable. Provide the obvious and step aside. Care about the developer (end-user), his/her environment, end goal, and existing competency.

Develop Something Scalable SweetPea has no dependencies which makes it extremely portable as a micro web framework. Designed to be used easily on shared hosting environments. When your ready for Virtual, Dedicated or Self Hosting, it scales like a good web application framework should.

Scales How? ...from the cli sweetpea make -–script Generates a minimalist application. (no deps beyond SweetPea and CGI). ...from the cli sweetpea make Generates an MVC fashioned application over top of the existing application. (refactoring optional)

Provide The Obvious Web application frameworks should be designed for the majority not the minority. The majority of application types, developers, environments, etc. This should be the number one consideration in framework development.

Care About The End-User SweetPea and SweetPea::Application provide a unified API for dealing with the "majority" of web application development issues. The API syntax is one of common sense, see if this makes sense to you: $s->email->message(...) $s->session->param(...) $s->validate->table(...) $s->template->render, etc.

Lead By Example SweetPea and SweetPea::Application are web application frameworks with the same ideology and architecture for different situations. SweetPea for small jobs, and SweetPea::Application for larger projects. Scale from SweetPea to SweetPea::Application with ease and without refactoring.

SweetPea SweetPea is a micro web application framework, meaning it only contains simple web application functionality such as URL routing, parameter access, etc. Remember the "contact-form" script? For all intents and purposes it is a web application that simply looks for input parameters from the browser and sends an email to the defined email address. Implementing this using Catalyst, Mojolicious, and SweetPea::Application would be overkill. SweetPea offers a means of starting small and scaling with minimal (to no) refactoring.

RTFM? Sure, end-users should read the accompanying documentation although a user-friendly framework will possess a coding-style and API that is of common-sense. e.g. my $s = sweet; $s->error->message(“Bug...");

Not A Dictator All showcased functionality is lazy-loaded via the SweetPea "plug" method which means that it exists for developers that prefer it but can be ignored or overwritten by developers that prefer something else. e.g. SweetPea::Application has a built in ORM (object relational mapper), $s->dbo->table->read->first->{column}, ...

… If you don't like SweetPea::Application::ORM or prefer DBIx::Class, Rose::DB or something else, integrate it via $s->plug('dbo', sub{ require 'qw(MyDB::Schema)'; return MyDB::Schema->connect($dbi_dsn, $user, $pass, \%dbi_params); }); then use it in Models, Views and Controllers as follows: e.g. $s->dbo->resultset('Table')->all

Convention Over Configuration "Designing for the majority and not the minority" as stated earlier, is simply another way of expressing the convention over configuration ideology. This is an important philosophy for a web framework that cares about its end-users because beginners and intermediate-level developers with varying competency need to achieve the same results as experienced developers. I figure, if your elite enough to prefer configuration over convention, your smart enough to figure out how to configure a framework that uses convention.

What Can SweetPea Do For You? Besides be the wind beneath your wings, SweetPea itself will produce a fast, solid and scalable application, but you should see for yourself.....

I Am SweetPea, This Is What I Do...

Route URLs to Actions my $s = sweet; $s->route({ '/' => sub { my $s = shift; ... }, '/example' => sub { ... }, '/other' => sub { shift->forward('/other_controller'); }, });

Define Global Startup and Shutdown Routines my $s = sweet; $s->route({ '/root/_startup' => sub { my $s = shift; # this happens all the time :) }, '/root/_shutdown' => sub { my $s = shift; ... } });

Forward and Detach like Catalyst my $s = sweet; $s->route({ '/test1' => sub { my $s = shift; $s->forward('/test2'); }, '/test2' => sub { my $s = shift; $s->detach('/test3'); } '/test3' => sub { my $s = shift; ... } });

Access Any Parameter my $s = sweet; $s->route({ '/:url_param' => sub { my $s = shift; $s->param('url_param'); }, '/test/*' => sub { my $s = shift; $s->param('*'); } '/test1' => sub { my $s = shift; $s->param('input'); # get or post param $s->param('session'); # session param } });

I Am SweetPea::Application, Now See What I Can Do...

Don't Need Routes Defined I run as a script under any web server. By default, URLs are matched using http:://localhost/(controller)/(action) my $s = sweet; $s->run;

Promotes Code Reuse Via MVC package Controller::YourController; package View::YourView; package Model::YourModel;

Execute Common Code Globally or Locally Automatically execute code locally or globally with each request... sub _startup { # in Controller/Root.pm ... } sub _shutdown { # in Controller/Root.pm ... }

Local Auto-Executing… in Controller/YourController.pm sub _begin { ... } sub _end { ... }

Hide Actions From The Browser Controller actions prefixed with an underscore are denied access from the browser. http://localhost/admin/_login = access denied package Controller::Admin; sub login { my ($self, $s) = @_; $self->_login($s) if ...; } sub _login { my ($self, $s) = @_; ... }

MVC All The Way Home The SweetPea MVC architecture promotes clean readable and reusable code, e.g. package Controller::Foo; sub _index { my ($self, $s) = @_; # reuse default data updating function (centralized) $s->model('Schema')->update_log; # reuse default template rendering (centralized) $s->view('Default')->render; }

Most Web Applications Send Email Since most web applications send email(s), doesn't it make sense to include that ability, ..., the answer is yes. $s->email->message({ to => ..., from => ..., subject => ..., message => ..., })->send('sendmail');

Send Emails How? # send using sendmail, $s->email->message({...})->send('sendmail'); # or SMTP $s->email->message({...})->send('smtp'); # or Both, or use one for Bulk Messages $s->email->message({...})->send('sendmail'); $s->email->message({...})->send('smtp');

Send Pretty Emails Most modern web applications want to send HTML emails for marketing, etc. Send application pages as email attachments without WWW. Yes, no sub HTTP request using LWP or WWW::Mechanize (which means access to pages can be secured using built-in authorization info (cookies), etc) …

… $s->email->message({ ..., message => ..., webpages => [ '/example/email/letter' => 'welcome_letter.html' ], attachments => [ 'file_and_location' => 'attachment_name' ] })->send('sendmail');

Won't Cost An ORM SweetPea::Application ships with an ORM (object- relational-mapper) that performs basic crud. e.g. The auto- generated database tables contains a users table and a permissions table and the ORM is aware of that. my $user = $s->dbo->users; $user->read; for (0..$user->count) { print $user->column; $user->column('new stuff'); $user->update($user->current, $user->id); }

Validate Input Manually or Automagically ... if $s->validate->table('users'); ... if $s->validate->profile('login'); my $input = $s->cgi->Vars; my $profile = { required => ['foo','bar','baz'] }; ... if $s->validate->input($input, $profile)

HTML Form and Table Tedium Eliminated (Or at least severely hindered...) my $profile = 'table/users'; # or whatever $s->builder->form($profile)->render; $s->builder->grid($profile)->render;

Leave The Security To The Framework (It Works) Role-Based Access Control (Super Flexible) my $access = $s->rbac; if ($access->authorized) { if ($access->role('manager')) { if ($access->can('/manage accounts/create account')) { # well I suppose we need to allow access } } }

Alter Configuration From The Application You provide the interface, we'll provide the ... my $configuration = $s->config->get('/application'); $configuration->{datastore} = 'production'; $s->config->set('/application');

Templates Within Templates my $t = $s->template; $t->render('navigation')->to('sidebar'); $t->render({ template => 'index', layout => 'default' }); ... Templates even have access to the unified API <a href=&quot;[% s.url('/static/index.html') %]&quot;>Link</a> [% content %] <div>[% t.sidebar %]</div>

English Is Not The Only Language my $l = $s->locale; $l->language('en'); my $text = $l->text('hello_message');

I'm Sold, How Do I Get Started?

… cpan SweetPea::Application Or cpan SweetPea

Make Something # a minimalist app sweetpea-app make -–script # or a standard sweetpea app sweetpea-app make –-basic # or a full-stack app sweetpea-app make --stack

Using A Database? sweetpea-app data –-create --dsn=dbi:pg:dbname=something --user=root

Be Fruitful and Multiply sweetpea-app model --name=NewModel sweetpea-app model --name=NewModel/Other sweetpea-app view --name=Email sweetpea-app view --name=Email/NewsLetter sweetpea-app ctrl --name=Admin sweetpea-app ctrl --name=Admin/Dashboard

In Summation $Awesome if 'SweetPea' or 'SweetPea::Application'; By Al Newkirk CPAN: awncorp IRC: perletc or awnstudio Twitter: newkirka