Uno de los errores comunes al implementar Smarty3 es:

Fatal error: Class ‘Smarty_Internal_Wrapper’ not found

Fatal error: Class ‘Smarty_Internal_Register’ not found

Fatal error: Class ‘Smarty_Internal_Template’ not found

Estos se deban, probablemente, a que en tu aplicación estás utilizando la función __autoload también necesaria por Smarty3. La solución a este problema pasa por utilizar la función que PHP nos brinda spl_autoload_register.

En una aplicación, sólo puede existir una llamada a la función __autload, sin embargo, con spl_autoload_register podemos añadir tantos manejadores como queramos y estos se irán ejecutando en el orden en el que los hayamos registrado.

Un ejemplo sencillo de su uso sería:

class AutoloadHandler
{
	static public function launch( $classname )
	{
		print '[['. $name .']]';
	}
}

spl_autoload_register( 'AutoloadHandler::launch' );

new ThisClassNotExists();

El resultado de ejecutar este script sería algo así:

[[ThisClassNotExists]]

Fatal error: Class ‘ThisClassNotExists’ not found in …

El cual nos indica que está llamando de manera correcta al autoload, pero al no estar implementado de manera correcta y no existir la clase ‘ThisClassNotExists’ nos devuelve un error.

En definitiva, para solventar el problema, no será necesario que modifiques el código Smarty, pues este ya está utilizando de manera correcta spl_autoload_register, lo que debes hacer es sustituir tu __autoload por una clase con una función ‘launch’ (llámala como quieras) y registrarla mediante:

<pre>spl_autoload_register( 'MyAutoloadHandler::launch' );</pre>

Si estás utilizando Smarty2 y te has decidido a dar el salto a Smarty3 para aprovecharte de sus nuevas funcionalidades (como por ejemplo la nada despreciable opción de herencia en templates), verás que existen algunas incompatibilidades, por ejemplo, se han decidido por seguir el estandar camelCase en el nombre de las funciones, utilizan getters y setters para los atributos o han cambiado la manera de registrar bloques.

En el caso del popular plugin smarty-gettext, si tenemos personalizada la llamada al traductor con, por ejemplo ‘{t}’ como es mi caso, nos encontraremos con un bonito error:

function call ‘register_block’ is unknown or deprecated

Esto es debido a que la forma correcta de registrar bloques en Smarty3 es:

$this->register->block('t', 'translate');

en lugar de:

$this->register_block( 't', 'translate' );

Una vez hecho esto, el siguiente error que nos deja Smarty es:

Plugin “t” not callable

En lugar del antiguo ‘translate’, el segundo parámetro deberá ser el nombre correcto de la función, es decir ’smarty_translate’:

$this->register->block('t', 'smarty_translate');

de este modo solventaremos el problema y podremos seguir disfrutando de nuestro plugin de traducción.

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

Qué es un ORM?

Un ORM o (Object Relation Mapper) es una técnica de programación que nos permite convertir datos entre el sistema de tipos utilizado en un lenguaje de programación orientado a objetos y el utilizado en una base de datos relacional, es decir, las tablas de nuestra base de datos pasan a ser clases y los registros objetos que podemos manejar con facilidad.

Utilizar un ORM tiene una serie de ventajas que nos facilitan enormemente tareas comúnes y de mantenimiento:

1. Reutilización: La principal ventaja que aporta un ORM es la reutilización permitiendo llamar a los métodos de un objeto de datos desde distintas partes de la aplicación e incluso desde diferentes aplicaciones.
2. Encapsulación: La capa ORM encapsula la lógica de los datos pudiendo hacer cambios que afectan a toda la aplicación únicamente modificando una función.
3. Portabilidad: Utilizar una capa de abstracción nos permite cambiar en mitad de un proyecto de una base de datos MySQL a una Oracle sin ningún tipo de complicación. Esto es debido a que no utilizamos una sintaxis MySQL, Oracle o SQLite para acceder a nuestro modelo, sino una sintaxis propia del ORM utilizado que es capaz de traducir a diferentes tipos de bases de datos.
4. Seguridad: Los ORM suelen implementar mecanísmos de seguridad que protegen nuestra aplicación de los ataques más comúnes como SQL Injections.
5. Mantenimiento del código: Gracias a la correcta ordenación de la capa de datos, modificar y mantener nuestro código es una tarea sencilla.

Qué es Doctrine?

Según la documentación oficial, Doctrine es un ORM para PHP 5.2.3 y posterior. Además de todas las ventajas que conlleva un ORM, uno de sus puntos fuertes es su lenguaje DQL (Doctrine Query Language) inspirado en el HQL de Hibernate.

Cuando trabajamos con Doctrine, necesitamos informar a su motor interno de cual es el modelo de nuestra aplicación, para ello podemos hacer ingeniería inversa de nuestra base de datos existente, o si empezamos la aplicación desde 0, crear el modelo en la sintaxis específica que nos propone Doctrine y luego generar toda la base de datos.

Para crear el modelo, doctrine nos da dos alternativas, hacer una clase por tabla e indicarle mediante PHP el tipo de datos que almacenaremos en él, un ejemplo:

// models/generated/BaseUser.php

class User extends BaseUser
{
    public function setTableDefinition()
    {
        $this->hasColumn('username', 'string', 255, array('default' => 'default username'));
        $this->hasColumn('name', 'string', 255, array('default' => 'default name'));
        $this->hasColumn('age', 'integer', 4, array('unsigned' => true));
        // ...
    }

    // ...
}

O crear un esquema en formato YAML (schema.yml) similar a XML, pero bastante más legible. El equivalente al ejemplo anterior en YAML sería:

# schema.yml

# ...
User:
# ...
  columns:
    username:
      type: string(255)
      default: default username
    name:
      type: string(255)
      default: default name
    age:
      type: integer(4)
      unsigned: true
    # ...

Además de definir los campos de cada tabla, también le indicamos las relaciones que tienen con las otras tablas y su tipo (many-to-many, one-to-many, one-to-one…), lo que deja perfectamente estructurada nuestro modelo de datos y su manera de acceder a los valores.

Más adelante seguiré escribiendo sobre las ventajas de Doctrine y añadiendo ejemplos que considere interesantes y/o útiles.

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.