/ 
PEF-Front-0.26
River stage one • 1 direct dependent • 1 total dependent
/ PEF::Front

NAME

PEF::Front - Perl Effective Web Framework

SYNOPSIS

 # startup.pl
 use MyApp::AppFrontConfig;
 use PEF::Front::Preload qw(no_db_connect);
 use PEF::Front::Route ('/' => '/appIndex');
 
 PEF::Front::Route->to_app();

 # MyApp::AppFrontConfig.pm
 package MyApp::AppFrontConfig;
 sub cfg_no_nls { 1 }
 sub cfg_no_multilang_support { 1 }
 
 1;
 
 # $project_dir/templates/index.html
 some Template-Toolkit style template.

DESCRIPTION

PEF::Front is a Perl web framework with following features.

Easy in development

You just write API of your application and it's automatically exposed as AJAX or data retrieving methods in your templates. HTML templates can be programmed separately.

Fast and versatile template engine

HTML templates can be programmed by other people who know nothing about Perl.

Explicit model methods description

Your API calls are described in YAML files. There're can be set default values, complex parameter checks, input parameter filters, output filters and other things.

HTML/AJAX developer can look into these YAML files to understand backend API.

Safe

Thanks very comprehensive parameter checks, passed into handler request is already checked and filtered, you don't need to make additional validation.

Flexible rules

Different output filters can be applied to the same data to get different data representation. Input data can be obtained automatically from session, headers, cookies, form and other sources. Results from handlers can set or unset headers or cookies. All this is described in YAML and all these rules are compiled into native Perl code.

Routing

Request routing is very powerful and effective. Your routing rules are compiled into native Perl code.

Highly configurable

There're many configurable parameters and functions. They have some sensible defaults that you have to configure only small part of them. It's very easy to configure them in your own *::AppFrontConfig module.

PSGI

PSGI is very effective protocol for passing incoming requests into application. You can use PEF::Front with any PSGI-server. I use uwsgi. It is also very wise to have some reverse-proxy server in front of PSGI-server for static content. I use Nginx.

More productive out of the box

PEF::Front has many components that a really useful for typical web applications:

Sessions

Session data can be automatically loaded during request validation.

Oauth2

There're components to easily make authorization on your site for Facebook, GitHub, Google, LinkedIn, MSN, PayPal, Vkontakte and Yandex users.

Localization support

There's a message translation support in templates and handlers and automatic language detection based on URL, HTTP headers and Geo IP.

Captcha

Captcha check during request validation. Simple captcha component. Custom captcha image generation is possible.

Websockets and Server Sent Events

Basically these technologies require some event loop architecture to reduce overhead on every connection. But it requires non-trivial callback code for series of complex queries to DB. It is possible to make in quite "usual" code using Coro + AnyEvent environment with DBIx::Connection::Pool for pool of asynchronous DBIx::Connectors. Thre's even DBIx::Struct ORM that supports such a pool of connectors.

Websockets and Server Sent Events are available as external modules.

Your Application

Project structure

Typical directory structure of Your application is alike:

+ $project_dir/
  + $app/
    + $Project/
      - AppFrontConfig.pm
      + InFilter/
      + OutFilter/
      + Local/
  + bin/
    - startup.pl
  + model/
  + templates/
  + var/
    + cache/
    + captcha-db/
    + tt_cache/
    + upload/
  + www-static/
    + captchas/
    + images/
    + jss/
    + styles/

You can redefine almost everything here except InFilter, OutFilter and Local directories.

What is what

bin

Different executables. startup.pl is one of them. Actually this file can have any name that is known to PSGI-server.

$app

Directory of main application code and AppFrontConfig.pm module. Framework determines it automatically from path to loaded AppFrontConfig.pm module.

$Project

Directory structure of application modules.

InFilter

Optional modules for input data validation.

OutFilter

Optional modules for transformation of output data.

Local

Incoming request handlers.

model

YAML-files with descriptions of model methods. Every file describes one method.

templates

Directory of templates. Currently only Template-Toolkit style is supported.

var/cache

Session data and cached responses of handlers.

var/captcha-db

Database for generated captchas.

var/tt_cache

Cache of compiled templates.

var/upload

Root directory for uploaded files.

www-static

Directory of static content. This is typically served by some fast web-server like Nginx.

www-static/captchas

Directory of generated captcha images. This is typically served by the same web-server for static content.

Minimal application

Minimal application can consist of only two files: AppFrontConfig.pm and setup.pl.

It would look like this:

 # MyApp::AppFrontConfig.pm
 package MyApp::AppFrontConfig;
 sub cfg_no_nls { 1 }
 sub cfg_no_multilang_support { 1 }
 
 1;

 # startup.pl
 use MyApp::AppFrontConfig;
 use PEF::Front::Response;
 use PEF::Front::Route;
 
 PEF::Front::Route::add_route(
  get '/' => sub {
     PEF::Front::Response->new(headers => ['Content-Type' => 'text/plain'], body => 'Hello World!');
   }
 );
 
 PEF::Front::Route->to_app();

You have to define minimal config and routes. Routes can return HTTP response directly.

More information

There're guides and demos.

Quick-Start guide
Configuration parameters
Model methods description
Routing of incoming requests
Template processing

AUTHOR

This module was written and is maintained by Anton Petrusevich.

Copyright and License

Copyright (c) 2016 Anton Petrusevich. Some Rights Reserved.

This module is free software; you can redistribute it and/or modify it under the same terms as Perl itself.