Catalyst

Recomiendo este libro a todo aquel que se quiera iniciar en Catalyst web Framework. Catalyst utiliza MVC. ¿Que es esto?:

Es una metodología o estilo para construir aplicacines que divide la implementación en modelo, vista y controlador. el modelo es la representación de la información con el cual opera el sistema. La vista representa el modelo en un formato de salida para interactuar con el usuario (GUI). El controlador es la parte del sistema que responde a eventos del usuario e interactua con el modelo con la info de entrada.

En las siguientes anotaciones podrás encontrar varios métodos de instalación para ubuntu (apt-get / CPAN), creación de un proyecto, anotaciones sobre el Helper TTSite, Action Types, FormBuilder, Template toolkit y un ejemplo practico. Espero que os sirva de iniciación :)

Instalación Catalyst Apt-get:

    
 - libcatalyst-perl
 - libcatalyst-engine-apache-perl
 - libcatalyst-model-cdbi-perl
 - libcatalyst-modules-extra-perl
 - libcatalyst-modules-perl
 - libcatalyst-view-tt-perl

Instalación Catalyst CPAN:

 - Catalyst::Runtime
 - Catalyst::Devel
 - Task::Catalyst
 - Catalyst::Model::DBIC::Schema
 - Catalyst::View::TT
 - DBD::SQLite
 - DBIx::Class

# catalyst.pl evento -> crea una la carpeta evento con el contenido:

 .
 |-- Changes
 |-- Makefile.PL
 |-- README
 |-- evento.conf
 |-- lib
 |   |-- evento
 |   |   |-- Controller
 |   |   |   `-- Root.pm
 |   |   |-- Model
 |   |   `-- View
 |   `-- evento.pm
 |-- root
 |   |-- favicon.ico
 |   `-- static
 |       `-- images
 |           |-- btn_120x50_built.png
 |           |-- btn_120x50_built_shadow.png
 |           |-- btn_120x50_powered.png
 |           |-- btn_120x50_powered_shadow.png
 |           |-- btn_88x31_built.png
 |           |-- btn_88x31_built_shadow.png
 |           |-- btn_88x31_powered.png
 |            |-- btn_88x31_powered_shadow.png
 |           `-- catalyst_logo.png
 |-- script
 |   |-- evento_cgi.pl
 |   |-- evento_create.pl
 |   |-- evento_fastcgi.pl
 |   |-- evento_server.pl
 |   `-- evento_test.pl
 `-- t
     |-- 01app.t
     |-- 02pod.t
     `-- 03podcoverage.t

Ahora lanzamos el Server Catalyst:

 $ script/evento_server.pl -r                -> Ejecutamos el servidor de Catalyst.
 Navegador -> http://localhost:3000          -> Ver pagina bienvenida

Nuestra controladora creada está ubicada en lib/evento/Controller y desde allí vamos a crear todos los método necesarios para nuestra aplicación.

 $ scritp/evento_create.pl Controller registro       -> Creamos un controlador
 $ script/evento_create.pl View participante TTSite  -> Creación de vistas participante

Creamos la carpeta root/src/"participante" y el archivo de vita participante.tt2

 $ vim participante.tt2
 _________________________________________
 | root/src/participante/participante.tt2 \
 --------------------------------------------------------------------------
 1 *p* Hola: [% nombre %] */p*
 --------------------------------------------------------------------------

uso (*) en lugar de (<) y (>) para presentar el código sin que lo interprete.

Modificamos:

    | lib/evento/Controller/registro.pm \
    --------------------------------------------------------------------------
    30 sub saludo : Local {
    31     my ( $self, $c) = @_;
    32
    33     $c->stash->{template} = “participante/participante.tt2“;
    34     $c->stash->{nombre}   = “Joel Gómez“;
    35 }
    --------------------------------------------------------------------------

En nuestra subrutina saludo lo que estamos haciendo es diciéndole a Catalyst cual es la vista que va a usar para ese método y paso una variable llamada nombre para la vista.

Helper TTSite: encapsula los trozos de lógica correspondientes a la presentación y al acceso a datos y componentes que necesite una vista, haciendo que la vista permanezca de esta forma mucho más simple reutilizable y mantenible. La lógica de presentación se encarga de formatear datos a través de Template Toolkit para que sean visualizados en una página, mientras que el acceso a datos o componentes implica la obtención de datos. TTSite tiene como debilidad que no podemos incluir Javascript’s o Css’s de manera razonable a una vista en particular (digo razonable porque si tratan de incluirlo entonces éste quedará fuera de la etiqueta de nuestro html generado). Por tal motivo tendremos que hacer unas pequeñas y sencillas modificaciones al Helper.

Actions Types: Los Actions Types es la forma mediante el cual Catalyst puede leer a la URL en la Controladora para luego hacer Match con los métodos dentro de ella. Los diferentes Actions son los siguientes:

- Path

sub metodo : Path(’save’) { }
Hace Match con el método save de la controladora http://localhost:3000/controlador/save esta también se puede usar de forma relativa al controlador en uso sub metodo : Path(‘/save’) { }
Hace Match con http://localhost:3000/save

- Local

sub metodo : Local { }
Hace Match con http://localhost:3000/controlador/metodo no hace falta colocarle los argumentos

- Global

sub metodo : Global { }
Es similar a la anterior solo que nuestra URL es http://localhost:3000/metodo se ignora el nombre de la controladora

- Regex

sub metodo : Regexp(^save) { }
Este hace uso de expresiones regulares para hacer match con la URL de manera Global, el resultado puede ser el siguiente:

        http://localhost:3000/save
        http://localhost:3000/save_usuario
        http://localhost:3000/save_evento

- LocalRegexp

sub metodo : LocalRegexp(^save) { }
Igual que el anterior pero ahora de manera local, la URL puede ser

        http://localhost:3000/controlador/save
        http://localhost:3000/controlador/save_usuario
        http://localhost:3000/controlador/save_evento

- Private

sub metodo : Private { }
Este nunca hará Match por la URL, es decir, no se puede acceder a este método mediante la URL, es privado de la controladora.

- Building-in Actions Special

Estas son acciones predefinida por Catalyst, las cuales son: index, auto, begin, end y default

- index     -> Usuario coloca solo nombre de controladora: Ej, http://localhost:3000/controlador
- auto      -> Se ejecuta despues de begin justo antes de procesar el metodo que hace Match con URL.
- begin     -> Nombre de controlador identificado y antes de hacer Match con otro se ejecuta begin.
- end       -> Se le llama despues de hacer Match con el metodo pasado por URL y ejecutar contenido.
- default   -> Si no consigue hacer Match con un metodo se ejecuta default.

FORMBUILDER

Conceptos básicos

FormBuilder está diseñado para manejar todas las partes de una solicitud de un formulario CGI - generación, la presentación y la validación. Como tal, aplicaciones de FormBuilder generalmente se bucle vuelta sobre sí mismos. Es decir, usted tendrá una sola secuencia de comandos que, cuando se invoca, se hará cargo de toda la aplicación sólo basándose en los parámetros CGI.

FormBuilder utiliza un Object-Oriented llamada-estilo, pero no permita que le espantar. Uso es sumamente fácil, ya que hay sólo dos funciones que necesita saber acerca de. A lo largo de la documentación, nuestro objeto de FormBuilder siempre se identificarán como $form, y encontrará esto funciona igualmente bien en sus propios scripts.

Estos son los pasos básicos:

1.Crear un objeto de $form con CGI::FormBuilder->new()
2.Definir los campos de formulario con el $form->field() método.
3.Comprobación de si el formulario se presentó con $form->submitted y si es así, validar con $form->validate.
4.Obtener valores individuales mediante la $form->field() método, y hacer todo lo que usted necesita con los datos
  (actualizar una base de datos, etc.).
5.Si el formulario no fue presentado (o se produce un error de validación), imprimirlo utilizando los principales
  $form->render función.

Esto es lo que hay que! FormBuilder se hará cargo de la generación de HTML y JavaScript, diseño de tabla, validación adherencia, mensajes de error y así sucesivamente. Echemos un vistazo a una secuencia de comandos de FormBuilder básico.

    #!/usr/bin/perl

    use CGI::FormBuilder;

    @fields = qw(first_name last_name email phone);

    $form = CGI::FormBuilder->new(
             fields => \@fields,
        );

    if ($form->submitted && $form->validate) {
        # you would write code here to act on the form data
        $fname = $form->field('first_name');
        $lname = $form->field('last_name');

        print $form->confirm(header => 1);
    } else {
        print $form->render(header => 1);
    }

En primer lugar, definimos nuestros campos y crear un nuevo objeto de $form especificar esos campos (tenemos que barra diagonal inversa nuestra matriz de \@fields para que se pasa de una sola pieza). A continuación FormBuilder les lleva, crea etiquetas legibles para cada campo y todo lo pone espera en una tabla HTML automáticamente por el $form->render método. De hecho, FormBuilder títulos incluso el nombre de la forma que se basa en el nombre de la secuencia de comandos. (personal_info.pl se convierte en "Información personal").

Cuando el usuario golpea el botón de "Enviar", $form->submitted devolverá true, que en nuestro ejemplo anterior también causaría $form->validate para ejecutar (debido a la && en la instrucción if). Si ambos devuelven true, significa que se presentaron datos de forma válida, y, a continuación, puede hacer cualquier cosa que necesite hacer con esos datos.

Llegar a los datos del formulario es tan fácil como con el método de field() en una forma similar a la función de param() de CGI.pm. La función de field() tiene numerosos otros usos, como veremos más adelante.

Detener para un segundo y ver esto en acción. A continuación, compruebe que el HTML generado por esta aplicación antes de pasar al siguiente paso.