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-UserSweetPea 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.

SweetPeaSweetPea 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 DictatorAll 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 Actionsmy $s = sweet;

$s->route({

'/' => sub {

my $s = shift;

...

},

'/example' => sub {

...

},

'/other' => sub {

shift->forward('/other_controller');

},

});

Define Global Startup and Shutdown Routinesmy $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 Catalystmy $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 Parametermy $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 MVCpackage 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 BrowserController 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 HomeThe 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 EmailsMost 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 ORMSweetPea::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 Templatesmy $t = $s->template;

$t->render('navigation')->to('sidebar');

$t->render({

template => 'index',

layout => 'default'

});

... Templates even have access to the unified API

<a href="[% s.url('/static/index.html') %]">Link</a>

[% content %] <div>[% t.sidebar %]</div>

English Is Not The Only Languagemy $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 Multiplysweetpea-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 NewkirkCPAN: awncorp

IRC: perletc or awnstudio

Twitter: newkirka