La verdad es que me he basado en uno existente para crearlo (AvalancheSitemapBundle), y la mayor diferencia entre ambos es que el de Avalanche123 está preparado para usarse con DoctrineMongoDB y el mio con Doctrine, por lo que los datos del sitemap se podrían almacenar en una BD MySQL.

La verdad es que no veía la necesidad de instalar mongodb exclusivamente para almacenar las URLs del sitemap y como no me parece descabellado usar la misma BD del proyecto para hacerlo, decidí que yo quería algo parecido a ese Bundle pero con MySQL, así que lo hice y aquí está.

Solo lo he probado en un proyecto y es una primera versión, así que puede que tenga algún que otro fallo, si los encontráis no dudéis en decírmelo (a través del Issue Tracker de Github por favor).

El siguiente paso en el desarrollo del bundle será añadirle la posibilidad de generar físicamente los ficheros del sitemap en disco y comprimirlos con gzip, para que no tenga que generar al vuelo el sitemap cada vez que hay una petición. Si además de esta se os ocurre alguna otra funcionalidad que os gustaría que le añadiera, ya sabéis, me lo contáis y lo valoro.

En un principio parece que sí, se accede vía web y sin ningún problema se van generando los ficheros de caché. Pero si más adelante ibas a la línea de comandos e intentabas alguna acción que tuviera que reescribir esos ficheros (generados por usuario apache o similar) te decía que el usuario que usabas no tenía permisos. Pues nada, yo volvía a darle permisos 777 con ayuda del sudo, hacía lo que tenía que hacer y de nuevo volvía a darle permisos para que el usuario apache no tuviera problemas en sobreescribir lo que yo había generado desde consola con mi usuario. Menudo lío ¿no?

Llegado un punto en el que este loop empezaba a convertirse en infinito, busqué un poquito y descubrí que no tenía que ir muy lejos a buscar la solución, estaba escrita en la propia documentación de Symfony2. Y realmente tampoco era tan complicada si hubiera pensado un poquito, ambos usuarios deben tener permisos sobre esos directorios:

sudo rm -rf app/cache/*
sudo rm -rf app/logs/*
sudo setfacl -R -m u:www-data:rwx -m u:`whoami`:rwx app/cache app/logs
sudo setfacl -dR -m u:www-data:rwx -m u:`whoami`:rwx app/cache app/logs

Dónde www-data es el nombre del usuario de los accesos web (en algunos casos es apache, http,…) y dónde whoami es el nombre del usuario con el que accedes y ejecutas la consola de Symfony.

// src/Acme/HelloBundle/Controller/HelloController.php

namespace Acme\HelloBundle\Controller;
use Symfony\Component\Security\Core\Authentication\Token\UsernamePasswordToken;

// ...

class HelloController
{
    public function barAction($foo)
    {
        // ...

        // Tienes que crear la entidad del usuario que quieres loguear, por ejemplo
        $em = $this->getDoctrine()->getEntityManager();
        $user = $em->getRepository('AcmeHelloBundle:User')->find($userId);

        // Si usas FOSUserBundle puedes sacar así el $providerKey
        $providerKey = $this->container->getParameter('fos_user.firewall_name');
        // Si no, puedes simplemente poner el nombre del firewall de tu aplicación
        $providerKey = 'main';

        // Si usas FOSUserBundle y has creado la entidad puedes sacar así los roles del user
        $roles = $user->getRoles();
        // Si no puedes hacerlo manualmente
        $roles = array('ROLE_USER');

        // Finalmente logueamos al usuario
        $token = new UsernamePasswordToken($user, null, $providerKey, $roles);
        $this->container->get('security.context')->setToken($token);

        // Y si lo crees necesario le rediriges con un mensajito
        $this->get("session")->setFlash('info', $this->get('translator')->trans('flash.logged_successfully'));

        return $this->redirect($this->generateUrl('homepage'));

        // ...
    }
}

Creo que no es mucho y que es sufientemente claro como para entenderlo sin más explicación que los comentarios del propio código, así que ahí queda. Si aún así os surge alguna dudilla que os pueda resolver hacedla en los comentarios, y con un poco de suerte y tiempo os contesto.

PD: Esta es mi inocentada, que creais que voy a retomar el blog como propósito de 2012 :p
PD2: Hoy estoy que lo doy todo, he programado otro post para la semana que viene.

Teniendo esto en cuenta me tengo que plantear un cambio, lo que tengo clarísimo es que con Symfony 1 no puedo seguir y como entiendo que el cambio más natural en un principio es Symfony2 he empezado con ello. No quiero decir que no me vaya a plantear otras posibilidades, por supuesto que sí, pero creo que es un buen punto para empezar, así que con ello estoy. Este cambio de framework va a necesitar en mi caso un esfuerzo extra porque a la vez me planteo el cambio casi seguro de Propel a Doctrine2 y de SVN a Git.

Creo que puedo resumir estas semanas en puntos que creo positivos y los que veo negativos:

• ↑ Estructura y flexibilidad. Me gusta mucho como viene estructurado, y el hecho de que incluso el core del framework sea considerado como cualquier otra librería externa de tu aplicación y a su vez esté separado en librerías independientes que puedes usar fuera de Symfony. Además, todo (y todo es todo) es personalizable en Symfony2 (a los plugins/widgets/módulos que permiten modificarlo ahora les llaman bundles), aunque por el momento muchas veces lo difícil es saber cómo.
• ↑ Modelo-Vista-Controlador. Ya en la versión 1 la separación era muy clara, pero creo que con Symfony2 y Doctrine esto se ha visto reforzada y me gusta. Otro punto a favor creo que es el nuevo sistema de plantillas que se propone con Symfony2 llamado Twig, que os recordará mucho a Smarty si alguna vez trabajásteis con él.
• ↑ Formularios. Creo que el nuevo sistema de formularios es más sencillo (uso) y a la vez más completo que el anterior. Uniéndolo con el ya mencionado sistema de plantillas Twig una bomba.
• ↑ ¿Rendimiento? Lo pongo con interrogantes porque la verdad es que aunque he oído maravillas aún no he tenido la posibilidad de probarlo en producción y no voy a asegurar lo que no he visto (¡un excéptico de pura cepa como yo!), pero la verdad es que visto lo visto creo que puede ser bastante cierto.

• ↓ Documentación. Sé que aún no ha salido la versión final estable, sé que es un framework que ‘acaba de empezar’, sé que cuesta mucho documentar totalmente un proyecto de esta envergadura, pero me fastidia un montón estar convencidísimo de que algo se puede hacer y no encontrar como hacerlo. Estoy seguro de que con el tiempo esto cambiará, pero por el momento creo que es un gran problema sobre todo si eliges un framework de este tipo para agilizar tus desarrollos.
• ↓ Requisitos y gigantismo. Creo que Symfony2 no es un framework para cualquiera, no lo veo como solución a proyectos pequeños, webs informativas de pymes o blogs por ejemplo. Además para su correcto funcionamiento en producción son necesarios ciertos requisitos que no puedes encontrar en todos los hostings, sobre todo si tienes algo compartido. Para empezar PHP 5.3 es totalmente necesario, entre otras cosas por el obligatorio uso de los namespaces. De todos modos los creadores de Symfony2 ya lo han tenido en cuenta y han creado Silex un microframework basado en Symfony para proyectos más pequeños que estoy deseando probar.
• ↓ Autogeneradores. Cuando no has probado el chocolate no sabes si te gusta, pero como te guste luego no puedes dejar de comerlo, y si no tienes pues lo hechas en falta. Esto es lo que me ha pasado con los administradores autogenerados de Symfony 1 que tanto trabajo me han ahorrado, y ahora que Symfony2 no los trae pues me parece una gran falta. El generador de CRUD con Doctrine2 puede ser un sustitutivo en parte, pero no es lo mismo.

Creo que esas pueden ser las conclusiones más importantes que he sacado estos primeros días. En una visión general y teniendo en cuenta que en Symfony2 aún quedan muchas cosas por hacer, creo voy a decir que en principio me gusta. Si os interesa el tema os dejo unos enlaces sobre el tema:

• Symfony2. Página oficial del framework.
• symfony.es. Página y comunidad de Symfony en español creada por Javier Eguiluz, alguien a quien merece la pena escuchar con atención.
• Ponencias de deSymfony2011. Vídeos y presentaciones de las jornadas deSymfony de este año. Aún no están colgados, pero está previsto que se vayan poniendo durante esta semana.
• Fabien Potencier. Creador del framework.
• Gente que sabe de esto: Javier Eguiluz, Asier Marqués, Albert Jessurum, Nacho Martín, Jon Segador

Sea o no mi decisión final quedarme con Symfony2 como alternativa a Symfony1 en los proyectos que ya he desarrollado, o los que vengan más adelante, estoy seguro de que no dejaré de investigar y probar cosas con él, así que seguro que seguiréis leyendo más cosas en Berriart referentes a este framework y ya sobre temas o usos más concretos.

Los que usamos Symfony no tenemos porque volvernos locos para usar Lucene, la API de Google GData, manejar PDFs, recoger feeds o tantas otras funcionalidades que cubre tan bien el Framework Zend. No, porque integrar Zend en Symfony viene a ser bastante sencillo:

Añadir la librería Zend a nuestro código

Debemos descargar el Framework Zend y copiarlo en lib/vendor, que es el directorio donde guardamos habitualmente las librerías externas. Ahí lo meteremos todo dentro de una carpeta nueva que llamaremos Zend.

Sistema para cargar Zend cuando lo necesitemos

Para esto lo que vamos a hacer es crear un método nuevo en la clase config/ProjectConfiguration.class.php que nos permita cargar Zend fácilemente desde cualquier parte:

class ProjectConfiguration extends sfApplicationConfiguration

  static protected $zendAutoloader = false;

  /** ............ **/

  /**
   * Agrega el framework Zend a nuestra App
   */
  static public function registerZend()
  {
    if(!self::$zendAutoloader)
    {
      set_include_path(implode(
        PATH_SEPARATOR,
        array(sfConfig::get('sf_lib_dir') . '/vendor', get_include_path())
      ));
      require_once 'Zend/Loader/Autoloader.php';
      self::$zendAutoloader = Zend_Loader_Autoloader::getInstance();
    }

    return self::$zendAutoloader;
  }
}

Empezamos a usarlo

Una vez hecho todo esto podríamos tranquilamente en un action o en algún task hacer uso del framework Zend. Por ejemplo…

// Cargamos el framework Zend
ProjectConfiguration::registerZend();

// Utilizamos Zend....
try {
  $feed = Zend_Feed_Reader::import($parameters['feed']);
} catch (Zend_Feed_Exception $e) {
  /** ........ **/
}

Como podéis ver eso es todo A continuación os pongo las diapos que pasó la gente de Symfony y Zend en las conferencias explicando la utilidad de integrarlos y donde explican como hacerlo que es de donde he sacado yo la info:

• Using Zend Framework and Symfony Together (Zend PHP Conference 2009)
• Using Zend Framework with Symfony (sfLive 2010)
• Integrating symfony and Zend Framework (IPC 2010)

Resulta que el proyecto tiene URLs como esta: http://efemerides20.com/4-de-diciembre. Dónde realmente estoy pasando dos variables por la URL: el 4 indicando el día, y ‘diciembre’ indicando el mes. Así que en el archivo routing.yml de Symfony he creado la ruta así:

day:
  url:   /:day-de-:month
  param: { module: efemeride, action: day }
  requirements: { month: \w+, day: \d+ }

Cuando he accedido, me ha saltado error 404 diciéndome que no había niguna ruta que coincidiera con esa URL. EL problema es que por defecto Symfony no entiende los guiones como separadores en la URL, y solo interpreta como tales el punto ‘.’ y la barra ‘/’. Si queremos cambiar esto y que la ruta definida funcione correctamente tenemos que añadir el punto a lo que Symfony entiende como separadores de segmentos en la URL. Para ello hay que modificar el fichero factories.yml de la aplicación en cuestión (en este caso frontend).

En ese fichero (apps/modules/frontend/config/factories.yml) hay un pequeño apartado dedicado al enrutamiento que seguramente y si no lo habéis cambiado pondrá lo siguiente:

  routing:
    class: sfPatternRouting
    param:
      generate_shortest_url:            true
      extra_parameters_as_query_string: true

Pues para hacer que nuestra ruta funcione solo hay que añadir un nuevo parámetro a esa configuración de la siguiente manera en mi caso:

  routing:
    class: sfPatternRouting
    param:
      generate_shortest_url:            true
      extra_parameters_as_query_string: true
      segment_separators: ['/', '.', '-']

Es decir, añadir en el parámetro segment_separators todos los caracteres que querráis permitir como separadores.

Esa inclusión se realiza en el filtro sfCommonFilter, por lo tanto lo primero es crear un filtro que sustituirá a ese y que colocará los javascripts donde nosotros queremos, al final. Lo incluiremos en la carpeta libs/filters y en este caso se llamara myProjectCommonFilter:

<?php
/**
* myProjectCommonFilter Helper
*
* myProjectCommonFilter automatically adds javascripts to the bottom of the page and stylesheets to the top in the sfResponse content.
* This class is based in the sfCommonFilter helper of the symfony package.
*
* @package    symfony
* @subpackage filter
* @author     Alberto Varela <alberto@berriart.com>
* @version    2010-07-07
*/
class myProjectCommonFilter extends sfFilter
{
  /**
  * Executes this filter.
  *
  * @param sfFilterChain $filterChain A sfFilterChain instance
  */
  public function execute($filterChain)
  {
    // execute next filter
    $filterChain->execute();

    // execute this filter only once
    $response = $this->context->getResponse();

    // include stylesheets
    $content = $response->getContent();
    if (false !== ($pos = strpos($content, '</head>')))
    {
      $this->context->getConfiguration()->loadHelpers(array('Tag', 'Asset'));

      if (!sfConfig::get('symfony.asset.stylesheets_included', false))
      {
        $html .= get_stylesheets($response);
      }

      if ($html)
      {
        $response->setContent(substr($content, 0, $pos).$html.substr($content, $pos));
      }
    }

    // include javascripts
    $content = $response->getContent();
    if (false !== ($pos = strpos($content, '</body>')))
    {
      $this->context->getConfiguration()->loadHelpers(array('Tag', 'Asset'));
      $html = '';
      if (!sfConfig::get('symfony.asset.javascripts_included', false))
      {
        $html .= get_javascripts($response);
      }

      if ($html)
      {
        $response->setContent(substr($content, 0, $pos).$html.substr($content, $pos));
      }
    }

    sfConfig::set('symfony.asset.javascripts_included', false);
    sfConfig::set('symfony.asset.stylesheets_included', false);
  }
}

Ahora solo tenemos que decirle a Symfony que queremos utilizar este nuevo filtro en vez del sfCommonFilter y para eso tenemos que modificar el fichero config/filters.yml de nuestra aplicación y cambiar el filtro common:

common:
  class: myProjectCommonFilter

En un principio eso es todo, pero debéis tener cuidado si también escribís código Javascript directamente en la página sin usar ficheros externos. Tened en cuenta que siempre que ese código ‘inline’ necesite utilizar alguna de las librerías externas deberá estar escrito por debajo de las llamadas a éstas y por lo tanto tendréis que modificar el filtro que os he puesto más arriba.