Antes de empezar a hacer el upgrade de symfony debemos asegurarnos que los plugins utilizados actualmente en el proyecto son compatibles con la versión 1.4, en caso de no ser compatibles, tenemos tres opciones:

1. Buscar un plugin similar que sí sea compatible.
2. Modificar nuestra aplicación para que no utilice dicho plugin.
3. Si no podemos prescindir de él, habrá que esperar a que saquen la compatibilidad o hackearlo nosotros mismos (lo qual podría ser muy fácil o muy difícil en función del tipo de problema).

Pasos a seguir para subir de versión:

1) Update de los canales de pear

sudo pear update-channels

2) Upgrade de symfony a la versión 1.3

sudo pear upgrade -f symfony/symfony-1.3.0

3) Validamos que no estamos usando métodos deprecated (estós están eliminados en la versión 1.4)

symfony project:validate

En caso de obtener errores del validador, los solventaremos antes de hacer el upgrade siguiendo instrucciónes en la página Deprecations and removals in 1.3

4) Upgrade del projecto a la versión 1.3

symfony project:upgrade1.3

5) Upgrade de los plugins a la última versión

symfony plugin:upgrade [plugin]

6) Upgrade de symfony a la última versión

sudo pear upgrade symfony/symfony

7) Limpiamos la caché antes de probar

symfony cc

Ahora deberíamos tener nuestro proyecto updateado a la última versión estable de symfony

Symfony permite varios métodos para internazionalizar nuestra aplicación. Por defecto, utilizan el formato XLIFF sin embargo, personalmente me gusta más gettext.

¿Cómo configurar symfony para usar gettext?

Para configurar symfony para que utilice gettext seguiremos los siguientes pasos:

1) Activamos el módulo I18N modificando el archivo settings.yml:

#apps/<appName>/config/settings.yml
all:
  .settings:
    charset:                utf-8
    i18n:                   on
    standard_helpers:       [ [TUS_HELPERS_ACTIVADOS]..., I18N]

2) Abrimos el archivo factories.yml y añadimos la entrada i18n:

#apps/<appName>/config/factories.yml
all:
  i18n:
    class: sfI18N
    param:
      default_culture:  en_US
      source:           gettext</pre>

3) Crearemos una carpeta i18n dentro de apps//:

apps/<appName>/i18n/<lang>

Donde <lang> será el idioma en dos letras (en, es, fr…) y dentro tendremos los ficheros messages.po y messages.mo.

Ahora podemos utilizar la función __( ‘texto_a_traducir’ ) con doble underscore [ _ ] en lugar del simple utilizado normalmente.

¿Cómo generar automáticamente nuestros ficheros po y mo?

Symfony trae una serie de herramientas que nos permiten generar los archivos po y mo de manera automática. Invocando el comando:

symfony i18n:extract frontend en --auto-save

Se recorrerá todos los archivos php de nuestra aplicación (código y templates) y sacará los textos que encuentre en las funciones __().

También se puede utilizar el mismo comando de la siguiente manera:

symfony i18n:extract frontend en --auto-delete

para eliminar las cadenas de texto que ya no existen.

Aquí os dejo algo de información sobre como solicitar variables de configuración en symfony además de un listado muy útil con todas las variables que Symfony trae predefinidas.

Cómo pedir variables definidas

Se puede llamar a la función estática get del objeto sfConfig para solicitar cualquier variable definida pasándo dos valores. El primero indica el nombre de la variable solicitada y el segundo, el valor que retornará en caso de no existir dicha variable.

sfConfig::get('sf_config_variable', 'The default value'); // The default is optional

Además de las variables que symfony trea configuradas por defecto, podemos añadir nuestras propias variables. Esto se hace en los archivos app.yml. Tenemos un app.yml global para todas las aplicaciones y módulos de nuestro proyecto localizado en:

/path/to/project/[PROJECT_NAME]/config/app.yml

y otro para cada una de las aplicaciones:

/path/to/project/[PROJECT_NAME]/apps/[APP_NAME]/config/app.yml

NOTA! Si existen dos variables con el mismo nombre en el app.yml global y en el de aplicación, este último valor sobreescribirá el valor global.

Para solicitar una variable definida en uno de estos archivos app.yml devemos añadir app_ al nombre de la variable como se muestra en el siguiente ejemplo:

sfConfig::get('app_sf_config_variable');

Si en el archivo app.yml definimos la variable en cascada, como por ejemplo:

all:
  admin:
    email: admin@mail.bla

Deberemos acceder a ella añadiendo los diferentes niveles en la llamada:

sfConfig::get('app_admin_email');
También podemos acceder a los valores configurados en settings.yml añadiendo el prefijo “sf_” al valor que queremos recuperar.

Variables definidas por Symfony Framework

sf_symfony_lib_dir

Path real a la carpeta lib del framework:

/usr/share/php/symfony/symfony12/lib

Project Structure and Layout

sf_root_dir

Path a la raiz del projecto:

/path/to/project/[PROJECT_NAME]

sf_apps_dir

Path a la carpeta “apps” del proyecto:

/path/to/project/[PROJECT_NAME]/apps

sf_lib_dir

Path a la carpeta “lib” del proyecto:

/path/to/project/[PROJECT_NAME]/lib

sf_log_dir

Path a la carpeta “log” del proyecto:

/path/to/project/[PROJECT_NAME]/log

sf_data_dir

Path a la carpeta “data” del proyecto:

/path/to/project/[PROJECT_NAME]/data

sf_config_dir

Path a la carpeta “config” del proyecto:

/path/to/project/[PROJECT_NAME]/config

sf_test_dir

Path a la carpeta “test” del proyecto:

/path/to/project/[PROJECT_NAME]/test/

sf_doc_dir

Path a la carpeta “doc” del proyecto:

/path/to/project/[PROJECT_NAME]/doc

sf_plugins_dir

Path a la carpeta de “plugins” del proyecto:

/path/to/project/[PROJECT_NAME]/plugins

sf_cache_dir

Path a la carpeta “cache” del proyecto:

/path/to/project/[PROJECT_NAME]/cache

sf_web_dir

Path a la carpeta pública “web”:

/path/to/project/[PROJECT_NAME]/web

sf_upload_dir

Path a la carpeta pública de “uploads”:

/path/to/project/[PROJECT_NAME]/web/uploads

Application Information

sf_app

El nombre de la aplicación en la que está el archivo, como por ejemplo “frontend” o “backend”.

sf_environment

Entorno de desarrollo actual como por ejemplo “dev”.

sf_debug

Devuelve el estado actual del modo debug. Puede estar activado “1″ o desactivado “0″.

Application Structure and Layout

sf_app_dir

Path a la carpeta de la aplicación actual:

/path/to/project/[PROJECT_NAME]/apps/[APP_NAME]

sf_app_config_dir

Path a la carpeta “config” de la aplicación actual:

/path/to/project/[PROJECT_NAME]/apps/[APP_NAME]/config

sf_app_lib_dir

Path a la carpeta “lib” de la aplicación actual:

/path/to/project/[PROJECT_NAME]/apps/[APP_NAME]/lib

sf_app_module_dir

Path a la carpeta “modules” de la aplicación actual:

/path/to/project/[PROJECT_NAME]/apps/[APP_NAME]/modules

sf_app_template_dir

Path a la carpeta “templates” de la aplicación actual:

/path/to/project/[PROJECT_NAME]/apps/[APP_NAME]/templates

sf_app_i18n_dir

Path a la carpeta “i18n” de la aplicación actual:

/path/to/project/[PROJECT_NAME]/apps/[APP_NAME]/i18n

Cache Structure and Layout

sf_app_base_cache_dir

Path a la carpeta de la aplicación actual dentro de la caché.

/path/to/project/[PROJECT_NAME]/cache/[APP_NAME]

sf_app_cache_dir

Path a la carpeta de la aplicación actual en el entorno de desarrollo actual dentro de la caché.

/path/to/project/[PROJECT_NAME]/cache/[APP_NAME]/dev

sf_template_cache_dir

Path a la carpeta “template” de la aplicación actual en el entorno de desarrollo actual dentro de la caché.

/path/to/project/[PROJECT_NAME]/cache/[APP_NAME]/dev/template

sf_i18n_cache_dir

Path a la carpeta “i18n” de la aplicación actual en el entorno de desarrollo actual dentro de la caché.

/path/to/project/[PROJECT_NAME]/cache/[APP_NAME]/dev/i18n

sf_config_cache_dir

Path a la carpeta “config” de la aplicación actual en el entorno de desarrollo actual dentro de la caché.

/path/to/project/[PROJECT_NAME]/cache/[APP_NAME]/dev/config

sf_test_cache_dir

Path a la carpeta “test” de la aplicación actual en el entorno de desarrollo actual dentro de la caché.

/path/to/project/[PROJECT_NAME]/cache/[APP_NAME]/dev/test

sf_module_cache_dir

Path a la carpeta “modules” de la aplicación actual en el entorno de desarrollo actual dentro de la caché.

/path/to/project/[PROJECT_NAME]/cache/[APP_NAME]/dev/modules

Application Settings

sf_error_404_module

Módulo que ha hecho saltar el error 404.

sf_error_404_action

Acción que ha hecho saltar el error 404.

sf_logging_enabled

Valor boleano que nos indica si el loggin de la web está activo “1″ o no “0″.

sf_escaping_strategy

Valor boleano que indica si la clase sfView está usando Escaping Strategy “1″ o no “0″.

sf_no_script_name

Valor boleano que indica si la aplicación requiere nombre de script.

sf_csrf_secret

La clave CSRF secreta configurada en la aplicación.

También:

Se puede acceder a la información del actual contexto con las siguientes funciones:

sfContext::getInstance()->getActionName();

Devuelve el nombre de la acción actual. También puede llamarse desde los templates con $this->getActionName().

sfContext::getInstance()->getModuleName();

Nombre del módulo actual. También puede llamarse desde los templates con $this->getModuleName().

sfContext::getInstance()->getModuleDirectory();

Path al directorio del módulo actual:

/path/to/project/[PROJECT_NAME]/apps/[APP_NAME]/modules/[MODULE_NAME]

sfFormExtraPlugin es un excelente plugin que mantienen los desarrolladores de Symfony con un montón de características adicionales que te ayudarán a construir formularios más completos.

¿Qué podemos encontrar en este plugin?

Són varias las utilidades que nos ofrece, desde la creación de campos captcha para evitar el spam hasta campos de texto autocompletables en función de lo que vayamos escribiendo. Aquí os dejo una lista con sus posibilidades:

1. ReCaptcha widget y validador
2. Editor HTML WYSIWYG para campos de texto
3. Selector de fechas tipo calendario
4. Selectores de idioma
5. Widget de listas dobles
6. Widget de autocompletado en campos de texto

¿Cómo instalar y usar sfWidgetFormJQueryDate?

sfWidgetFormJQueryDate nos creará un selector de fechas con unas configuraciones mínimas para facilitar la tarea de rellenar los campos date en nuestros formularios. En la siguiente imágen, puedes ver el resultado de su correcta implementación:

A pesar de que este plugin está muy extendido, es muy poca la información que se puede encontrar sobre como instalarlo y usarlo correctamente. Espero que esta pequeña guía os sea de utilidad.

1. Instalar el plugin:
   symfony plugin:install sfFormExtraPlugin
2. Una vez instalado, también necesitaremos descargar las librerías jQuery UI de la web oficial.
3. Ahora debemos configurar convenientemente nuestra aplicación para que use estas librerías javascript. Abre el zip descargado y mueve los archivos jquery-1.3.2.min.js y jquery-ui-1.7.2.custom.min.js a tu carpeta /path/to/project/web/js/Edita el archivo /path/to/project/apps/[app]/config/view.yml y añade esta información:
   javascripts:    [jquery-1.3.2.min.js, jquery-ui-1.7.2.custom.min.js]
4. El siguiente paso será configurar los CSS de la librería jQuery UI. Añadimos  la siguiente información al archivo view.yml recién editado:
   stylesheets:    [main.css, ui-lightness/jquery-ui-1.7.2.custom.css]
5. Configurar nuestro formulario para que utilice el widget:

   class myForm extends sfForm {
     public function configure()
     {
       $this->setWidgets(array(
         'from_date'    => new sfWidgetFormJQueryDate(array(
         'image'=> '/images/icons/calendar_view_month.gif',
         'format' => '%day%/%month%/%year%')
       ),
         //...other widgets
       ));
   
       $this->widgetSchema->setLabels(array(
     		'from_date'    => 'From Date',
                   //...other labels
       ));
     }
   }

6. Por último, lo prepararemos para usar en el action:

     public function executeSearch(sfWebRequest $request){
       $this->form = new myForm();
       return sfView::SUCCESS;
     }

   y renderizaremos en la vista:

   ....
   echo $form['from_date']->renderLabel().":".$form['from_date'];
   ....

Vía | Symfonynerds.com

Vamos a ver como informar al magnífico ORM Doctrine de que debe tratar un par de tablas con una relación many-to-many utilizando una tabla intermedia.

Supongamos que tenemos una talba de jugadores de fútbol y una tabla de equipos. Un equipo estará compuesto por varios jugadores y a su vez, un jugador puede estar relacionado con varios equipos (el actual, más los equipos por los que ha pasado en su vida deportiva).

Para este ejemplo necesitaremos tres tablas: Team, Player  y una relacional TeamPlayer. El schema.yml de este escenario sería:

# Player table
Player:
  tableName: player
  columns:
    id:
      type: integer(4)
      unsigned: 1
      primary: true
      autoincrement: true
    first_name: string(255)
    last_name: string(255)
    weight: float(2147483647)
    height: float(2147483647)
  relations:
    Team:
      <strong>class</strong>: Team
      <strong>local</strong>: player_id
      <strong>foreign</strong>: team_id
      <strong>refClass</strong>: TeamPlayer

#Team table
tableName: team
  columns:
    id:
      type: integer(4)
      unsigned: 1
      primary: true
      autoincrement: true
    name: string(255)
  relations:
    Player:
      <strong>class</strong>: Player
      <strong>local</strong>: team_id
      <strong>foreign</strong>: player_id
      <strong>refClass</strong>: TeamPlayer

#TeamPlayer table
TeamPlayer:
  tableName: team_player
  columns:
    team_id:
      type: integer(4)
      unsigned: 1
      primary: true
    player_id:
      type: integer(4)
      unsigned: 1
      primary: true

Los puntos importantes están en las relaciones de las tablas Team y Player, donde indicaremos los campos:

• class: La clase encargada de manejar el objeto relacionado.
• local: El nombre del campo que hace de vínculo entre la tabla en la que estoy y la tabla relacional TeamPlayer
• foreign: El nombre del campo que hace de vínculo entre la tabla relacionada y la tabla relacional TeamPlayer
• refClass: Nombre del objeto encargado de realizar la relación

Siguiendo estos pasos podremos acceder a todos los equipos de un jugador y a todos los jugadores de un equipo sin ningún problema.

Symfony integra Propel ORM por defecto, sin embargo, Doctrine está ganando puntos sobre su rival.

La principal ventaja de cada uno de ellos es:

Propel: Está completamente integrado con Symfony y decenas de plugins sólo funcionan para Propel.

Doctrine: Tiene muy buen rendimiento en ejecución y una forma muy concisa al escribir consultas complejas.

Si te has decidido a utilizar Doctrine en lugar de Propel y no sabes como integrarlo con Symfony, aquí te dejo los pasos para activarlo.

1. Lo primero que deberemos hacer es habilitar sfDoctrinePlugin y deshabilitar sfPropelPlugin, esto lo haremos editando el archivo config/ProjectConfiguration.class.php :

   public function setup()
   {
     $this->enablePlugins(array('sfDoctrinePlugin'));
     $this->disablePlugins(array('sfPropelPlugin'));
   }
   

   o si lo prefieres, puedes habilitar todos los plugins por defecto excepto los que no te interesen:

   public function setup()
   {
     $this->enableAllPluginsExcept(array('sfPropelPlugin'));
   }
   

2. Activado Doctrine, borraremos la caché para asegurarnos que se cargan nuestros cambios:
   symfony cc
3. Crearemos una carpeta doctrine dentro de config que contendrá nuestro archivo schema.yml y listo, ya tenemos a Symfony funcionando con Doctrine
4. Ahora sólo queda abrir el archivo config/databases.yml y cambiar “propel” por “doctrine” (respetando mayúsculas y minúsculas) y eliminar la linea “classname:  PropelPDO“.

Recordemos que a partir de ahora, deberemos utilizar la sintaxis Doctrine, tanto en nuestra definición del schema como en el modelo de nuestra aplicación. Si son tus primeros pasos con Doctrine, puedes ver su documentación original aquí.

FullCalendar es un plugin jQuery que nos permite implementar de manera sencilla un calendario con una interfaz visual excelente y muy fácil de personalizar. Además, podemos hacer Drag&Drop (arrastrar y soltar) de los eventos agendados para pasarlos de un día a otro.

Hoy vamos a montar en symfony un módulo que nos mostrará un calendario con los eventos almacenados en nuestra base de datos. La parte de administración no la desarrollaré, pero con las completas herramientas que nos ofrece symfony, nos será muy fácil montarlo (si estás dando tus primeros pasos con Symfony, te recomiendo realizar este tutorial donde podrás ver paso a paso como se implementa un projecto con Symfony).

Generando y configurando el proyecto

Empezaremos desde el principio, creando el proyecto, la aplicación frontend y el módulo calendar:

symfony generate:project calendar
symfony generate:app frontend
symfony generate:module frontend calendar

Ahora conectamos nuestro proyecto con la base de datos modificando el archivo /path/to/project/config/databases.yml

all:
  propel:
    class:        sfPropelDatabase
    param:
      classname:  PropelPDO
      dsn:        mysql:dbname=<strong>[DB-NAME]</strong>;host=localhost
      username:   <strong>[DB-USER]</strong>
      password:   <strong>[DB-PASS]</strong>
      encoding:   utf8
      persistent: true
      pooling:    true

Nuestro siguiente paso será añadir la estructura de base de datos al archivo /path/to/project/config/schema.yml

propel:
  cal:
    id: ~
    description: {type:varchar(50), required: true }
    category: {type: integer, foreignTable: cal_category, foreignReference: id, required: true}
    details: {type:varchar(255), required: true }
    dstart: {type: date, required: true }
    dend: {type: date, required: true }
    created_at: ~
    updated_at: ~
    _indexes:
      intra_cal_I_1: [dstart]
      intra_cal_I_1: [dend]

  cal_category:
    id: ~
    category: {type:varchar(50), required: true, index: unique}
    created_at: ~
    updated_at: ~

y ahora, desde línea de comandos, indicaremos a symfony que genere la base de datos y el modelo de datos, para ello, ejecutamos:

symfony propel:build-all

Con estos pasos ya tenemos preparado nuestro proyecto para integrar FullCalendar… manos a la obra!

Integrando FullCalendar

El primer paso será bajarnos jQuery y FullCalendar de las páginas oficiales. Después guardamos los js jquery.min.js, fullcalendar.min.js, ui.draggable.js y ui.core.js en la carpeta /path/to/project/web/js y el css fullcalendar.css en /path/to/project/web/css.

Suele ser buena práctica definir las rutas antes de empezar a programar.  Dejaremos la ruta por defecto para mostrar el calendario, pero modificaremos la que nos muestra los detalles para indicarle que debe usar la clase sfPropelRoute que nos permitirá obtener el objeto job sin necesidad de generar la consulta SQL. Abrimos el archivo /path/to/project/apps/frontend/config/routing.yml y le añadimos:

cal_show_event:
  url:   /:module/:action/id/:id
  class:   sfPropelRoute
  options: { model: Cal, type: object }
  param:   { module: calendar, action: show }

El siguiente paso será implementar los eventos del mes actual hacia adelante, añadiendo la siguiente función al archivo /path/to/project/lib/model/CalPeer.php

  static public function getCalEvents(){
    // crea el inicio de mes
    $IniMes = date('d-m-Y',mktime(0,0,0,date('m'),1,date('Y')));
    $criteria = new Criteria();
    $criteria->add(self::DSTART, $IniMes, Criteria::GREATER_EQUAL);
    return self::doSelect($criteria);
  }

En el index de nuestro módulo /path/to/project/apps/frontend/modules/calendar/actions/actions.class.php llamámos a esta función:

  public function executeIndex(sfWebRequest $request)
  {
    $this->cal_list = CalPeer::getCalEvents();
  }
  public function executeShow(sfWebRequest $request)
  {
    $this->cal = $this->getRoute()->getObject();
  }

Ahora es el momento de crear la vista /path/to/project/apps/frontend/modules/calendar/templates/indexSuccess.php

<?php use_stylesheet('fullcalendar.css') ?>
<script type='text/javascript'>

$(document).ready(function() {

var d = new Date();
var y = d.getFullYear();
var m = d.getMonth();

$('#calendar').fullCalendar({
draggable: true,
events: [
<?php $total = count($intra_cal_list); $i=0; ?>
<?php foreach ($cal_list as $intra_cal): ?>
{
<?php $i++; ?>
id: <?php echo $intra_cal->getId() ?>,
title: "<?php echo $intra_cal->getDescription() ?>",
<?php
$fecha = strtotime($intra_cal->getDstart());
$anno = date("Y", $fecha);
$mes = date("m", $fecha);
$mes--;
$dia = date("d", $fecha);
?>
start: <?php echo "new Date(".$anno.", ".$mes.", ".$dia.")"; ?>,
<?php
$fecha = strtotime($intra_cal->getDend());
$anno = date("Y", $fecha); $mes = date("m", $fecha);
$mes--;
$dia = date("d", $fecha);
?>
end: <?php echo "new Date(".$anno.", ".$mes.", ".$dia.")"; ?>,
url: "<?php echo url_for('cal/show?id='.$intra_cal->getId()) ?>"
}<?php if ($i != $total) echo "," ?>
<?php endforeach; ?>
]
});

});

</script>

<div id='calendar'></div>

y la vista que nos mostrará el detalle de un evento /path/to/project/apps/frontend/modules/calendar/templates/showSuccess.php

<h1><?php echo $cal->getDescription()?></h1>
<?php echo $cal->getDetails() ?>

Por último, añadimos las siguientes líneas al layout /path/to/project/apps/frontend/templates/layout.php

<?php use_javascript('jquery.min.js') ?>
<?php use_javascript('fullcalendar.min.js') ?>
<?php use_javascript('ui.core.js') ?>
<?php use_javascript('ui.draggable.js') ?>

Hecho esto, si accedemos a nuestra aplicación desde el navegador http://localhost/web/calendar/index veremso nuestro calendario funcionando.

Esta artículo es la segunda parte de mis primeros pasos con Symfony, puedes ver la primer parte de como crear un proyecto con Symfony, donde se describe paso a paso como diseñar y generar el proyecto, crear las aplicaciones y los módulos y conectar nuestro proyecto con la base de datos.

En esta segunda parte, vamos a dar forma a la parte pública y privada,  hacer uso del scaffolding para generar las acciones comunes CRUD (Create, Read, Update, Delete) o como tunear las URLs para conseguir un mejor posicionamiento.

Dando forma a la parte privada backend

Generalmente, la parte de administración de cualquier web suele ser una tarea bastante repetitiva y poco agradable de realizar. Para simplificarlo, Symfony dispone de un modulo de Scaffolding que nos facilitará enormemente la tarea, creando el código necesario para hacer las operaciones básicas de creación, lectura, modificación y borrado de registros en base de datos.

Vamos a crear la parte de administración de nuestros dos módulos (posts y comments) con el comando propel:init-admin donde clase es la clase PHP que se encarga de representar la tabla de datos:

symfony propel:init-admin backend post Post
symfony propel:init-admin backend comment Comment

Pues ya tenemos creada las operaciones CRUD de las dos tablas, si visitamos la url http://localhost/blog/post, veremos un listado (de momento vacío) y un botón para crear nuestro primer post. En esta imágen, podemos ver el resultado del listado de posts:

Listado de posts

y en esta otra, el formulario de alta/modificación:

Edición de Posts

La parte de gestión de comentarios es idéntica a la de los artículos, salvo que en este caso, el formulario de creación del comentario también muestra la clave externa que hace referencia a los artículos. Para mostrar la clave externa, Symfony utiliza el método mágico de PHP llamado __toString().

Si no se ha definido este método, se muestra directamente el valor numérico de id. Si se quiere mostrar el título del post en lugar de su id, tan sólo se debe definir el método mágico __toString() en la clase del modelo de los artículos (en el archivo lib/model/Post.php):

Si ahora queremos, añadir un buscador a nuestra página de resultados de comentarios, modificar las columnas que se muestras o el número de resultados por página, lo podemos hacer de una manera simple añadiendo información al archivo generator.yml del módulo de comentarios (/var/www/blog/apps/backend/modules/comment/config/generator.yml).

Añadiendo la siguiente información al archivo:

generator:
  class:              sfPropelAdminGenerator
  param:
    model_class:      Comment
    theme:            default
    list:
      display:        [author, body]
      filters:        [post_id, author, body]
      max_per_page:   5

Conseguimos modificar el número de resultados por página, las columnas mostradas y añadir una caja buscadora:

Filtrado en lista de comentarios

Puedes ver todas las opciones de personalización que nos da el generador aquí.

Nota!! Después de cualquier cambio en un archivo *.yml es necesario que eliminemos la caché de Symfony para ver los resultados por pantalla. Para ello, ejecutamos desde consola symfony cc.

Dando forma a la parte pública frontend

La parte pública, tiene un desarrollo más manual pero aprovecharemos las utilidades que Symfony pone a nuestra disposición para darle forma.

Creamos los modulos del frontend (post y comment) lanzando desde consola la instrucción:

symfony generate:module frontend post
symfony generate:module frontend comment

Si visitamso la dirección http://localhost/blog/post, veremos la página inicial de Symfony. Este módulo, debería mostrar, por ejemplo, un listado de los posts publicados actualmente y al acceder a uno de ellos, mostrar la página de la noticia.

Para crear las acciones de listado y muestra, modificaremos el archivo /var/www/blog/apps/frontend/modules/post/actions/actions.class.php y añadiremos los dos métodos que se encargarán de realizarlas:

Ok, ya le hemos indicado al módulo que dispone de dos acciones más, listar y mostrar, además, le hemos indicado a la acción por defecto ‘index’ que haga una redirección hacia la acción ‘list’, por lo tanto, si visitamos http://localhost/blog/post o http://localhost/blog/post/list obtendremos el mismo resultado.

Llegados a este punto, es interesante explicar como es capaz Symfony de llegar al módulo indicado, la acción correcta y como llama a los templates adecuados. Como habreis deducido, Symfony es capaz de rescatar el módulo y la acción a partir de la URL que escribimos en el navegador, así bien, la URL tiene un formato:

http://dominio.foo/<modulo>/<accion>/<key_var_1>/<value_var_1>/…

Más adelante, veremos que se pueden personalizar las URLs para hacerlas más atractivas a los buscadores, pero por el momento, seguiremos trabajando con los valores por defecto.

Symfony irá a buscar un template html en la carpeta /var/www/blog/apps/frontend/modules/post/templates con el nombre <nombreAccion>+<ResultadoAccion> (en este caso listSuccess.php), parseará las variables y devolverá el resultado por pantalla.

El siguiente paso, será indicar al controlador (post/actions/actions.class.php) que solicite al modelo los posts existentes en base de datos y que se los pase a la vista. El resultado en forma de código sería:

Nota!! Todo valor establecido en la variable this de una acción será asignado automáticamente a la vista con el mismo nombre. En este caso, podremos utilizar $posts en el template listSuccess.php.

Ahora vamos a dar forma al template html que muestra el listado de posts. Creamos el archivo listSuccess.php en la carpeta de templates e insertamos esta información:

La primera línea se encarga de instanciar el helper Text, que nos permite usar la función truncate_text encargada de recortar el texto a 200 caracteres. También hacemos uso de link_to, disponible sin necesidad de instanciar ningún helper, encargada de crear un enlace con el texto “Continuarl leyendo…”  hacia la dirección indicada en el segundo parámetro.

Una vez tenemos la página de listado de posts, montaremos la que muestra la noticia. Añadiremos la siguiente información al método executeShow de la clase actions.class.php del módulo post:

El código recoge el parámetro id pasado por GET y  solicita al modelo el post con el id recogido. Si no existe el post solicitado, mostramos un error 404, en caso contrario, mostraremos la página resultante. El template asociado a esta acción sería:

y lo guardaremos con el nombre showSuccess.php en la carpeta de templates.

Modificando la URL por defecto

A peasr de que las URLs que compone Symfony por defecto son bastante semánticas, en este caso, sería interesante que, en lugar del id de post, aparezca el título del mismo por temas de posicionamiento en buscadores.

El enrutameinto se puede definir por aplicación modificando el archivo /var/www/blog/apps/<aplicacion>/config/routing.yml. Por defecto, este archivo contiene unas reglas básicas que modificaremos para dar a la URL el aspecto que deseemos.

Nuestro objetivo es conseguir una url de este estilo:

http://localhost/blog/post/lorem-ipsum-et-dolor/12

Para ello, añadiremos la siguiente entrada al archivo de routing después de el bloque default_index:

show_by_title:
  url:     /post/:title/:id
  param:   { module: post, action: permalink }

Esto, enviará cualquier URL de el estilo definido a la acción permalink que debemos crear en la clase actions.class.php del módulo post:

En este caso, nos basta con redireccionar a la acción show ya que en el método que muestra la noticia se recogerá el identificador y pintará los datos. Para más información sobre routing, puedes visitar la guía de Symfony.

Con esto tienes unas priemras nociones para poner en marcha una aplicación, en cualquier caso, puedes aprender más sobre Symfony en la documentación oficial, en el grupo Symfony de Google o en futuros artículos de este blog

Después de ver que es Symfony e instalar Symfony en nuestra máquina, voy a poner los pasos que he seguido, y los problemas que me he encontrado (junto con su resolución) para crear mi primer proyecto con Symfony.

Antes de ponernos manos a la obra, es imporatante entender como estructura Symfony el código. Todo proyecto creado por Symfony consta de una serie de carpetas y archivos que contienen el código base del framework. El árbol de carpetas de un proyecto es:

A su vez, los proyectos están divididos en aplicaciones y módulos, los cuales, suelen coincidir con las tablas de nuestra base de datos. En este primer proyecto, haremos un blog muy simple y le pondremos el nombre blog (para ser original), a su vez, estará formado por dos aplicaciones, el frontend (o la parte visible para los usuarios comunes) y el backend (el panel de administración). Por último, cada una de las aplicaciones tendrá dos modulos: post y comment:

Estructura proyecto Symfony

Base de datos del proyecto

Para la base de datos de este primer proyecto, crearemos un modelo muy simple que constará de una tabla de posts y una tabla de comentarios con una relación 1:n, puesto que un post puede tener n comentarios.

Base de datos

Creando el proyecto

Una vez tenemos clara la definición de la base de datos, las aplicaciones y los módulos del proyecto, podemos empezar a dar forma a nuestro código.

1. El primer paso será crear mediante el script que nos proporciona Symfony, un proyecto vacío, para ello, creamos una carpeta blog en, por ejemplo, /var/www/ y ejecutamos symfony generate:project <project>:

   mkdir -p /var/www/blog/
   cd /var/www/blog/
   symfony generate:project blog

   Esto nos habrá creado todo el árbol de directorios y archivos necesarios para poner en marcha nuestra web con este framework.

   NOTA!! Dependiendo del sistema operativo y de la instalación realizada, puede ser necesario utilizar el prefijo php antes de cada comando symfony (por ejemplo: > php symfony new blog)

2. Ahora, le pediremos a Symfony que nos genere las dos aplicaciones definidas anteriormente: frontend y backend

   symfony generate:app --escaping-strategy=on --csrf-secret=UniqueSecret frontend
   symfony generate:app --escaping-strategy=on --csrf-secret=UniqueSecret backend

   Al llamar a la tarea generate:app, también hemos pasado dos opciones relacionadas con la seguridad:

   • –escaping-strategy: Permite escapar la salida para evitar ataques XSS
   • –csrf-secret: Permite tokens de sesión en los formularios para prevenir los ataques CSRF
3. El siguiente paso, será conectar nuestra aplicación con la base de datos, para ello, Symfony dispone de un archivo de configuración /var/www/blog/config/databases.yml en el que le indicaremos donde está localizada, a que base de datos y con que usuario y contraseña lo deberá hacer.Para este caso, daremos por hecho que la base de datos es MySQL, se encuentra en la máquina local y que estará codificada en utf8. Abrimos el archivo y modificamos los valores que pongo en negrita:

   all:
     propel:
       class:        sfPropelDatabase
       param:
         classname:  PropelPDO
         dsn:        mysql:dbname=DB-NAME;host=localhost
         username:   DB-USER
         password:   DB-PASSWORD
         encoding:   utf8
         persistent: true
         pooling:    true

   Con esto, ya tenemos configurado nuestro proyecto con la base de datos!!

4. Una vez definida la conexión con la base de datos, creamos en el archivo /var/www/blog/config/schema.yml el esquema de la base de datos que representa el modelo de datos del proyecto:

   propel:
     post:
       _attributes:   { phpName: Post }
       id:
       title:         varchar(255)
       excerpt:       longvarchar
       body:          longvarchar
       created_at:
       updated_at:
     comment:
       _attributes:   { phpName: Comment }
       id:
       post_id:
       author:        varchar(255)
       email:         varchar(255)
       body:          longvarchar
       created_at:
       updated_at:

   Symfony, permite insertar una serie de opciones o atributos en su esquema de la base de datos, como por ejemplo phpName, que indica el nombre de la clase PHP utilizada para manejar cada tabla, además de ser capaz de deducir información del typo de campo a partir del nombre de la columna. Si por ejemplo una columna se llama id, salvo que se le indique lo contrario, Symfony supone que es la clave primaria de la tabla y, por tanto, que es de tipo entero, que no puede tomar valores null y que su valor se autoincrementa.

   Puedes ver más información sobre la syntaxis del esquema en la guía Symfony definitiva.

5. Ahora que tenemos definido el esquema, ejecutamos el comando propel:build-model para generar en la carpeta /var/www/blog/lib/model las clases que se encargan de manejar la base de datos

   symfony propel:build-model

   NOTA!! Si en este punto, aparece un error “Could not perform XLST transformation. Make sure PHP has been compiled/configured to support XSLT.” es debido a que no tienes instalada la extensión xsl para PHP. Desde Ubuntu puedes instalarla con sudo apt-get instal php5-xsl

6. Ya estamos listos para decirle a symfony que nos genere el script de creación de base de datos y lanzarlo:

   symfony propel:build-sql
   mysql -u DB-USER -p DB-NAME < /var/www/blog/data/sql/lib.model.schema.sql

   Nota!! Si antes de empezar el proyecto Symfony ya dispones de una base de datos, puedes hacer el trabajo inverso: generar el esquema y las clases PHP a partir de una base de datos existente.

7. Nos vamos a nuestro navegador y visitamos la dirección http://localhost/blog/,si todo ha ido bien, deberíamos estar viendo una página similar a esta:
   

   Nota!! Si la página te aparece sin imágenes ni estilos, bájate el archivo comprimido de Symfony Sandbox y descompríme sólo la carpeta /sf_sandbox/web/sf/ dentro de /var/www/blog/web/, con esto verás las imágenes y estilos del entorno recién creado.

Para que no me quede este post demasiado largo, lo he dividido en dos. En la segunda parte de “Mi primer proyecto con Symfony 1.2.7” veremos como dar forma a la parte pública y privada, hacer uso del scaffolding para generar las acciones comunes CRUD (Create, Read, Update, Delete) o configurar el aspecto de las URLs.

El otro día os comentaba que és Symfony. Hoy os voy a explicar como instalarlo paso a paso de cuatro modos distintos, mediante PEAR, de los repositorios oficiales de Ubuntu/Debian, desde los repositorios Subversion y descargandonos el archivo de la web.

Cualquiera de las opciones que aquí os expondré són igualmente válidas para acondicionar nuestra máquina y usar Symfony, sin embargo, recomiendo instalarlo mediante PEAR o de los repositorios de Ubuntu/Debian para facilitar la actualización posterior.

Instalación PEAR

Esta instalación requiere de la versión de PEAR 1.4.0 o superior.

1. Añadimos el channel de Symfony escribiendo desde línea de comandos:

   pear channel-discover pear.symfony-project.com

2. Instalamos la última versión (actualmente la 1.2.7) ejecutando este comando con permisos de administrador:

   sudo pear install symfony/symfony-1.2.7

Desde los repositorios oficiales de Ubuntu/Debian

Podemos instalar este completo framework PHP en Ubuntu y Debian haciendo:

1. Añadimos en el arcihvo /etc/apt/sources.list el repositorio de Symfony

   # Symfony
   deb http://www.symfony-project.org/get debian/

2. Actualizamos los listados de nuestra Ubuntu ejecutando con permisos de administrador:

   sudo apt-get update

3. Por último, instalamos Symfony ejecutando:

   sudo apt-get install php5-symfony

Desde los repositorios Subversion

Symfony pone a nuestra disposición sus repositorios Subversion de código para que podamos hacer un checkout del código:

1. Creamos una carpeta en un lugar accesible desde nuestro navegador, por ejemplo /var/www/<folder>:

   mkdir -p /var/www/<folder>
   cd /var/www/<folder>

2. Hacemos el checkout del código:

   svn co http://svn.symfony-project.com/branches/1.2

Descargando desde la web

Por último, también podemos ir a la página oficial de Symfony y descargarnos el último archivo estable. Abrimos una línea de comandos y hacemos:

1. Descargamos el último archivo estable (en mi caso la versión 1.2.7):

   wget http://www.symfony-project.org/get/symfony-1.2.7.tgz

2. Creamos una carpeta en un lugar accesible desde nuestro navegador, por ejemplo /var/www/<folder>:

   mkdir -p /var/www/<folder>
   cd /var/www/<folder>

3. Descomprimimos el archivo en ella:

   tar xvzf /path/to/symfony-1.2.7.tgz

Si bien, la documentación oficial de este framework es bastante extensa y clara, para cualquier duda, visitarla haciendo click aquí.