[Parte 3] El modelo del Blog: Usando Doctrine 2 y accesorio

Symfony, Tutoriales

Este post es la parte 3 de 6 del artículo: Creando un Blog con Symfony2

Debido a que la web de udelabs lleva varías semanas sin funcionar a petición de un par de usuarios me tomo la libertad de subir el tutorial traducido por ellos, quizás con alguna modificación que iba haciendo pero todos los méritos son de ellos.Tutorial en inglés 

Descripción

En este capítulo comenzaremos a explorar el modelo del blog. Implementaremos el modelo con el Object Relation Mapper (ORM o Asignador Objeto↔Relacional) Doctrine 2Doctrine 2 nos proporciona la persistencia de nuestros objetos PHP. También proporciona un dialecto SQL llamado Doctrine Query Language (DQL o lenguaje de consulta doctrine). Además de Doctrine 2, también introduciremos el concepto de datos de prueba. Los datos de prueba (en adelante: accesorios) son un mecanismo para llenar nuestras bases de datos de desarrollo y probar con datos de prueba adecuados. Al final de este capítulo habrás definido el modelo del blog, actualizando la base de datos para reflejar el nuevo modelo, y creado algunos accesorios. También habremos construido las bases para la página show del blog.

Doctrine 2: El modelo

Para que funcione nuestro blog necesitamos una manera de guardar los datos. Doctrine 2 proporciona un ORM diseñado exactamente para este propósito. El ORM de Doctrine 2 se encuentra en lo alto de una potente Capa de abstracción de base de datos que nos da la abstracción de almacenamiento a través del PDO de PHP. Esto nos permite utilizar una serie de distintos motores de almacenamiento, incluyendoMySQLPostgreSQL y SQLite. Vamos a utilizar MySQL para nuestro motor de almacenamiento, pero, lo puedes sustituir por cualquier otro motor que desees.

Si no estás familiarizado con algún ORM, vamos a explicar su principio básico. La definición en Wikipedia dice:
“Object-relational mapping (ORM, O/RM, and O/R mapping) in computer software is a programming technique for converting data between incompatible type systems in object-oriented programming languages. This creates, in effect, a “virtual object database” that can be used from within the programming language.”
En la que las habilidades del ORM traducen desde datos de una base de datos relacional como MySQL en objetos PHP que podemos manipular. Esto nos permite encapsular la funcionalidad que necesitamos en una tabla dentro de una clase. Piensa en una tabla de usuarios, probablemente esta tenga campos como usernamepasswordfirst_namelast_nameemail y dob (siglas de day of birth o en Español “fecha de nacimiento”). Con un ORM esta se convierte en una clase con las propiedades usernamepasswordfirst_name, etc., que nos permite llamar a métodos tales como getUsername() y setPassword(). Los ORMvan mucho más allá de esto, sin embargo, también son capaces de recuperar tablas relacionadas para nosotros, ya sea al mismo tiempo que recupera el objeto usuario, o de manera diferida en el futuro. Ahora, consideremos que nuestro usuario tiene algunos amigos con los que está relacionado. Para ello deberíamos tener una tabla de amigos, almacenando la clave primaria de la tabla usuario dentro de ella. Usando elORM ahora podríamos hacer una llamada como $user->getFriends() para recuperar objetos de la tabla de amigos. Si eso no es suficiente, el ORM también se ocupa de guardarlos por lo tanto puedes crear objetos en PHP, llamar a un método como save() y permitir que el ORM se ocupe de los detalles de en realidad persistir los datos en la base de datos. Debido a que estamos usando el ORM de Doctrine 2, te familiarizarás mucho más con lo que es un ORM a medida que avancemos a través de esta guía.
Si bien en esta guía utilizaremos el ORM de Doctrine 2, puedes optar por usar la biblioteca Object Document Mapper (ODM o Asignador Objeto↔Documento) de Doctrine 2. Hay una serie de variaciones de esta biblioteca incluyendo implementaciones de MongoDB y CouchDB. Ve la página del Proyecto Doctrine para más información.
También hay un artículo en el recetario que explica cómo configurar el ODM con Symfony2.

La entidad Blog

Vamos a empezar creando la clase entidad Blog. Ya tuvimos nuestro primer encuentro con las entidades en el capítulo anterior cuando creamos la entidad Enquiry. Puesto que el objetivo de una entidad consiste en almacenar datos, el sentido común nos dicta que debemos usar una para representar una entrada del blog. Al definir una entidad no estamos diciendo que automáticamente los datos se asignarán a la base de datos. Lo vimos con nuestra entidad Enquiry en la cual los datos contenidos en la entidad se enviaron por correo electrónico sólo al administrador del sitio.

Crea un nuevo archivo situado en src/Blogger/BlogBundle/Entity/blog.php y pega el siguiente contenido:

[codesyntax lang=”php” title=”src/Blogger/BlogBundle/Entity/Blog.php”]

[/codesyntax]

Como puedes ver, esta es una simple clase PHP. No extiende a ninguna clase y no hay manera de acceder a sus propiedades. Cada una de las propiedades se ha declarado como protegida por lo que no puedes acceder a ellas cuando operas en un objeto de esta clase. Podríamos declarar los captadores y definidores de estos atributos nosotros mismos, pero Doctrine 2 proporciona una tarea para hacerlo. Después de todo, la escritura de métodos de acceso no es la más emocionante de las tareas de codificación.

Antes de poder ejecutar esta tarea, le tenemos que informar a Doctrine 2 cómo debe asignar la entidad blog a la base de datos. Tal información se especifica en forma de metadatos utilizando las asignaciones deDoctrine 2. Puedes especificar los metadatos en una serie de formatos, incluyendo YAMLPHPXML y Anotaciones. En esta ocasión usaremos anotaciones. Es importante señalar que no es necesario persistir todas las propiedades de la entidad, por lo tanto no deberás proporcionar metadatos para estas. Esto nos da la flexibilidad de elegir sólo las propiedades que necesitamos asigne Doctrine 2 a la base de datos. Remplaza el contenido de la clase entidad blog situada en src/Blogger/BlogBundle/Entity/blog.php con lo siguiente:

[codesyntax lang=”php” title=”src/Blogger/BlogBundle/Entity/Blog.php”]

[/codesyntax]

En primer lugar hemos importado y apodado el espacio de nombres del ORM de Doctrine 2. Este nos permite utilizar anotaciones para describir los metadatos de la entidad. Los metadatos proporcionan información sobre cómo se deben asignar las propiedades a la base de datos.

Hemos utilizado un pequeño subconjunto de los tipos de asignación proporcionados por Doctrine 2. Puedes encontrar una lista completa de los tipos de asignación en el sitio web de Doctrine 2. Más adelante presentaremos otros tipos de asignación.

Si observaste atentamente el fragmento de código anterior te habrás dado cuenta de que la propiedad $comments no tiene metadatos. Esto es a propósito y se debe a que no necesitamos guardarlo, únicamente proporciona una colección de comentarios relacionados con una entrada del blog. Si piensas en esto sin tomar en cuenta la base de datos tiene sentido. Los siguientes fragmentos de código lo demuestran.

[codesyntax lang=”php”]

[/codesyntax]

El fragmento anterior muestra el comportamiento normal que te gustaría entre un blog y la clase comentario. Internamente, podríamos haber implementado el método $blog->addComment() de la siguiente manera.

[codesyntax lang=”php”]

[/codesyntax]

El método addComment sólo añade un nuevo objeto comentario a la propiedad $comnents del blog. Recuperar los comentarios también sería muy sencillo.

[codesyntax lang=”php”]

[/codesyntax]

Como puedes ver la propiedad $comments es sólo una lista de objetos ComentarioDoctrine 2 no cambia cómo funciona esto. Doctrine 2 será capaz de llenar automáticamente la propiedad $comments con objetos relacionados con el objeto blog.

Ahora que hemos dicho cómo asigna Doctrine 2 las propiedades a la entidad, podemos generar los métodos de acceso usando la siguiente orden:

$ php app/console doctrine:generate:entities Blogger

Notarás que la entidad Blog se ha actualizado con métodos de acceso. Cada vez que hagas algún cambio en los metadatos del ORM a las clases de nuestra entidad, puedes ejecutar esta orden para generar cualquier captador adicional. Esta orden no hará modificaciones a los métodos de acceso existentes en la entidad, por lo tanto tus métodos de acceso existentes nunca se van a remplazar con esta orden. Esto es importante ya que más tarde puedes personalizar algunos de los métodos de acceso predeterminados.

Aunque hemos utilizado anotaciones en nuestra entidad, es posible convertir la información de asignación a otros formatos de asignación apoyados usando la tarea doctrine:mapping:convert. Por ejemplo, la siguiente orden convertirá las asignaciones en la entidad de arriba al formato YAML.

$ php app/console doctrine:mapping:convert –namespace=”BloggerBlogBundleEntityBlog” yaml src/Blogger/BlogBundle/Resources/config/doctrine

Esto creará un archivo ubicado en src/Blogger/BlogBundle/Resources/config/doctrine/ /Blogger.BlogBundle.Entity.Blog.orm.yml que contendrá las asignaciones de la entidad blog en formato yaml.

La base de datos

Creando la base de datos

Si has seguido el capítulo 1 de esta guía, deberías haber utilizado el configurador web para establecer la configuración de la base de datos. Si no, actualiza las opciones database_* en el archivo de parámetros situado en app/parameters.yml.

Es tiempo de crear la base de datos usando otra tarea de Doctrine 2. Esta tarea sólo crea la base de datos, esta no crea las tablas dentro de la base de datos. Si existe una base de datos con el mismo nombre, la tarea generará un error y la base de datos existente quedará intacta.

$ php app/console doctrine:database:create

Ahora estamos listos para crear la representación de la entidad Blog en la base de datos. Hay dos maneras en que podemos lograrlo. Podemos utilizar la tarea schema de Doctrine 2 para actualizar la base de datos o podemos usar las más potentes migraciones de Doctrine 2. Por ahora vamos a utilizar la tarea schema. Veremos las migraciones de Doctrine en el siguiente capítulo.

Creando la tabla blog

Para crear la tabla blog en nuestra base de datos, puedes ejecutar la siguiente tarea de Doctrine.

Esto ejecutará el código SQL necesario para generar el esquema de base de datos para la entidad blog. Además le puedes pasar la opción --dump-sql de la tarea para volcar el SQL en lugar de ejecutarlo contra la base de datos. Si ves tu base de datos notarás que la tabla blog se ha creado, con los campos que configuraste en la información de asignación.

Hemos utilizado una serie de tareas de la línea de ordenes de Symfony2, y en verdadero formato de línea de ordenes, todas las tareas proporcionan ayuda, especificando la opción --help. Para ver los detalles de la ayuda para la tarea doctrine:schema:create, ejecuta la siguiente orden:

$ php app/console doctrine:schema:create –help

La información de ayuda será la salida que muestra el uso, y opciones disponibles. La mayoría de las tareas vienen con una serie de opciones que puedes configurar para personalizar el funcionamiento de la tarea.

Integrando el modelo con la vista: Mostrando una entrada del blog

Ahora hemos creado la entidad blog, y actualizamos la base de datos para reflejarlo, podemos empezar a integrar el modelo con la vista. Vamos a empezar construyendo la página para mostrar nuestro blog.

La ruta para mostrar el Blog

Empecemos creando una ruta para la acción show que mostrará un blog. Un blog se identifica por su ID único, por lo tanto ese ID tendrá que estar presente en la URL. Actualiza el archivo de enrutadoBloggerBlogBundle ubicado en src/Blogger/BlogBundle/Resources/config/routing.yml con lo siguiente:

[codesyntax lang=”php” title=”src/Blogger/BlogBundle/Resources/config/routing.yml”]

[/codesyntax]

Debido a que el ID del blog debe estar presente en la URL, hemos especificado un marcador de posición id. Esto significa que las direcciones URL similares a http://symblog.co.uk/1 yhttp://symblog.co.uk/my-blog coincidirán con esta ruta. Sin embargo, sabemos que el identificador del blog debe ser un entero (definido de esta manera en las asignaciones de la entidad) por lo tanto podemos agregar una restricción especificando que esta ruta sólo concordará cuando el parámetro id contenga un número entero. Esto se logra con el requisito id: d+ de la ruta. Ahora sólo el primer ejemplo de URLanterior coincidiría, http://symblog.co.uk/my-blog ya no coincide con esta ruta. También puedes ver que una ruta coincidente ejecutará la acción show del controlador BloggerBlogBundle del Blog. Este controlador aún no lo hemos creado.

El controlador de la acción Show

El pegamento entre el modelo y la vista es el controlador, por lo tanto aquí es donde vamos a empezar a crear la página show. Podríamos añadir la acción show a nuestro controlador Page existente, pero como esta página se refiere a la exhibición de una entidad blog sería más adecuado crear su propio controlador en el blog.

Crea un nuevo archivo situado en src/Blogger/BlogBundle/Controller/BlogController.php con el siguiente contenido:

[codesyntax lang=”php” title=”src/Blogger/BlogBundle/Controller/BlogController.php”]

[/codesyntax]

Hemos creado un nuevo controlador para la entidad Blog y definimos la acción show. Debido a que especificamos un parámetro id en la regla de enrutado en el BloggerBlogBundle_blog_show, este se pasará como argumento del método showAction. Si hubiéramos especificado más parámetros en la regla de enrutado, también se pasarían como argumentos independientes.

Las acciones de controlador también pasarán un objeto SymfonyComponentHttpFoundationRequest si lo especificas como un parámetro. Este puede ser útil cuando se trata con formularios. Ya hemos utilizado un formulario en el capítulo 2, pero no utilizamos este método ya que utilizamos un método ayudante de SymfonyBundleFrameworkBundleControllerController así:

[codesyntax lang=”php” title=”src/Blogger/BlogBundle/Controller/PageController.php”]

[/codesyntax]

En su lugar lo podríamos haber escrito de la siguiente manera:

[codesyntax lang=”php” title=”src/Blogger/BlogBundle/Controller/PageController.php”]

[/codesyntax]

Ambos métodos consiguen el mismo resultado. Si tu controlador no extendiera la clase ayudante SymfonyBundleFrameworkBundleControllerController no podrías utilizar el primer método.

Lo siguiente que necesitamos es recuperar la entidad Blog desde la base de datos. En primer lugar, utilizaremos otro método ayudante de la clase SymfonyBundleFrameworkBundleControllerControllerpara obtener el Entity Manager (en adelante: gestor de entidades) de Doctrine 2. El trabajo del gestor de entidades es manejar la persistencia y recuperación de objetos hacia y desde la base de datos. Por lo tanto, utilizaremos el objeto EntityManager para obtener el repositorio de Doctrine 2 para la entidad BloggerBlogBundle:Blog. La sintaxis especificada aquí es simplemente un atajo que puedes utilizar con Doctrine 2en lugar de especificar el nombre completo de la entidad, es decir, BloggerBlogBundleEntityBlog. Con el objeto repositorio llamamos al método find() pasándole el argumento $id. Este método recuperará el objeto por medio de su clave primaria.

Finalmente comprobamos que se ha encontrado la entidad, y pasamos esta entidad a la vista. Si no se encuentra una entidad lanzamos uns createNotFoundException. La cual en última instancia, va a generar una respuesta 404 No se ha encontrado.

El objeto repositorio te da acceso a una serie de útiles métodos ayudantes, incluyendo:

[codesyntax lang=”php”]

[/codesyntax]

Vamos a crear nuestras propias clases Repositorio personalizadas en el siguiente capítulo, cuando requeriremos de consultas más complejas.

La vista

Ahora que hemos construido la acción show para el controlador Blog nos podemos enfocar en mostrar la entidad Blog. Como especifica la acción show, se debe reproducir la plantillaBloggerBlogBundle:Blog:show.html.twig. Vamos a crear esta plantilla ubicada en src/Blogger/BlogBundle/Resouces/views/Blog/show.html.twig con en el siguiente contenido:

[codesyntax lang=”php” title=”src/Blogger/BlogBundle/Resouces/views/Blog/show.html.twig “]

[/codesyntax]

Como es de esperar empezamos extendiendo el diseño principal de BloggerBlogBundle. A continuación remplazamos el título de la página con el título del blog. Esto será útil para el SEO puesto que el título de la página del blog es más descriptivo que el título establecido por omisión. Por último vamos a sustituir el bloque body para mostrar el contenido de la entidad Blog. Aquí, de nuevo utilizamos la función asset para reproducir la imagen del blog. Las imágenes del blog se deben colocar en el directorio web/images.

CSS

A fin de garantizar que el blog muestre una bella página, le tenemos que añadir un poco de estilo. Actualiza la hoja de estilos situada en src/Blogger/BlogBundle/Resouces/public/css/blog.css con lo siguiente:

[codesyntax lang=”css”]

[/codesyntax]

Si no estás utilizando el método de enlaces simbólicos para hacer referencia a los activos del paquete en el directorio web, ahora debes volver a ejecutar la tarea de instalación de activos para copiar los cambios en tuCSS.

$ php app/console assets:install web

Debido a que hemos construido el controlador y la vista para la acción show echemos un vistazo a la página para ver su apariencia. Apunta tu navegador a http://symblog.dev/app_dev.php/1. ¿No es la página que estabas esperando?

Error 404 Pagina no encontrada

Symfony2 generó una respuesta 404 No se ha encontrado. Esto es porque no tenemos datos en nuestra base de datos, por lo tanto no se pudo encontrar alguna entidad coincidente con el id igual a 1.

Podrías simplemente insertar una fila en la tabla blog de tu base de datos, pero ahora vamos a utilizar un método mucho mejor; Datos de prueba.

Datos de prueba

Podemos usar accesorios para poblar la base de datos con algunas ‘muestras/datos de prueba’. Para ello utilizaremos la extensión y paquete Fixtures de Doctrine. La extensión y paquete Fixtures de Doctrine no viene con la edición estándar de Symfony2, los tenemos que instalar manualmente. Afortunadamente, esta es una tarea muy sencilla. Abre el archivo deps (por dependencias) ubicado en la raíz de tu proyecto y añade la extensión fixtures de Doctrine y el paquete de la siguiente manera:

[codesyntax lang=”text”]

[/codesyntax]

En seguida actualiza tus proveedores para reflejar estos cambios.

$ php bin/vendors install

Esto descargará la versión más reciente de cada uno de los repositorios de Github y los instalará en el lugar deseado.

Si estás usando una máquina que no tiene instalado Git tendrás que descargar e instalar manualmente la extensión y el paquete.
Extensión doctrine-fixtures: Descarga la versión actual de la extensión data-fixtures desde GitHub y expande su contenido en vendor/doctrine-fixtures.
DoctrineFixturesBundle: Descarga la versión actual del paquete DoctrineFixturesBundle desde GitHub y la expande su contenido en vendor/bundles/Symfony/Bundle/DoctrineFixturesBundle.

A continuación actualiza el archivo app/autoloader.php para registrar el nuevo espacio de nombres. Dado que DataFixtures también está en el espacio de nombres DoctrineCommon esto debe estar por encima de la directiva DoctrineCommon existente puesto que especifica una nueva ruta. Los espacios de nombres son revisados ​​de arriba hacia abajo por lo tanto los espacios de nombres más específicos se deben registrar antes de los menos específicos.

[codesyntax lang=”php” title=”app/autoloader.php”]

[/codesyntax]

Ahora vamos a registrar el DoctrineFixturesBundle en el núcleo situado en app/AppKernel.php:

[codesyntax lang=”php” title=”app/AppKernel.php”]

[/codesyntax]

Accesorios para el Blog

Ahora estamos listos para definir algunos accesorios para nuestros blogs. Crea un archivo de accesorios en src/Blogger/BlogBundle/DataFixtures/ORM/BlogFixtures.php y añádele el siguiente contenido:

[codesyntax lang=”php” title=”src/Blogger/BlogBundle/DataFixtures/ORM/BlogFixtures.php”]

[/codesyntax]

El archivo de accesorios muestra una serie de características importantes cuando se utiliza Doctrine 2, incluyendo la forma en que se persisten las entidades en la base de datos.

Vamos a ver cómo podemos crear una entrada en el blog.

[codesyntax lang=”php”]

[/codesyntax]

Comenzamos creando un objeto blog y establecimos ciertos valores a sus propiedades. En este punto Doctrine 2 no sabe nada del objeto Entidad. Es únicamente cuando hacemos una llamada a $manager->persist($blog1) que se informa a Doctrine 2 que inicie la gestión de este objeto entidad. Aquí, el objeto $manager es una instancia del objeto EntityManager que vimos anteriormente para recuperar entidades desde la base de datos. Es importante señalar que si bien Doctrine 2 ya está al tanto del objeto entidad, aún no lo ha guardado en la base de datos. Para ello se requiere una llamada a $manager->flush(). El métodoflush provoca que Doctrine 2 realmente interactúe con la base de datos y lleve a cabo las acciones en todas las entidades que está gestionando. Para un mejor rendimiento deberías agrupar las operaciones deDoctrine 2 y limpiarlas todas en conjunto de una sola vez. Así es como lo hicimos en nuestros accesorios. Creamos cada entidad, pidiendo a Doctrine 2 que las gestionara y luego, al final, limpiamos todas las operaciones.

Cargando los accesorios

Ahora estamos listos para cargar los accesorios a la base de datos.

$ php app/console doctrine:fixtures:load

Si echamos un vistazo a la página show en http://symblog.dev/app_dev.php/1 deberías ver el blog apropiado.

Mostrar Blog

Intenta cambiar el parámetro id en la URL a 2. Deberías ver la siguiente entrada del blog.

Si echas un vistazo a la URL http://symblog.dev/app_dev.php/100 deberías ver que se ha lanzado una excepción 404 No se ha encontrado. Esperábamos que no hubiera una entidad Blog con un id de 100. Ahora intenta con la URL http://symblog.dev/app_dev.php/symfony2-blog. ¿Por qué no obtuvimos una excepción 404 No se ha encontrado? Esto se debe a que la acción show nunca se ejecuta. La URLno coincide con ninguna ruta en la aplicación debido al requisito d+ que pusimos en la ruta BloggerBlogBundle_blog_show. Es por eso que ves una excepción No hay ruta para "GET /symfony2-blog".

Marcas de tiempo

Finalmente en este capítulo vamos a ver las dos propiedades de fecha y hora en la entidad Blogcreated y updated. La funcionalidad para estas dos propiedades comúnmente se conoce como el comportamientoTimestampable (en adelante: autofechable). Estas propiedades mantienen la hora y fecha en que se creó el blog y la fecha y hora de la más reciente actualización del blog. Puesto que no queremos tener que configurar manualmente estos campos cada vez que creamos o actualizamos un blog, podemos utilizar dos ayudantes de Doctrine para ello.

Doctrine 2 viene con un Sistema de eventos el cual proporciona retrollamadas en el ciclo de vida. Podemos utilizar estos eventos retrollamados para que al registrar nuestras entidades notifiquen los eventos durante la vida útil de la entidad. Algunos ejemplos de eventos que podemos notificar incluyen a antes de que se produzca una actualización, después de un guardado exitoso y después de ocurrida una eliminación. Con el fin de utilizar las retrollamadas del ciclo de vida de nuestra entidad es necesario registrar la entidad para ello. Esto se hace usando los metadatos de la entidad. Actualiza la entidad blog ubicada ensrc/Blogger/BlogBundle/Entity/Blog.php con lo siguiente:

[codesyntax lang=”php” title=”src/Blogger/BlogBundle/Entity/Blog.php”]

[/codesyntax]

Ahora vamos a añadir un método en la entidad Blog para registrar el evento preUpdate. También vamos a añadir un constructor para establecer los valores predeterminado para las propiedades created yupdated.

[codesyntax lang=”php” title=”src/Blogger/BlogBundle/Entity/Blog.php”]

[/codesyntax]

Registramos la entidad Blog para que sea notificada cuando ocurra el evento preUpdate para establecer el valor de updated. Ahora, cuando se vuelva a ejecutar la tarea para cargar accesorios notarás que las propiedades created y updated se ajustan automáticamente.

Debido a que las propiedades autofechables son un requisito común para las entidades, hay un paquete disponible que las apoya. El StofDoctrineExtensionsBundle ofrece una serie de útiles extensiones paraDoctrine 2 incluyendo Sluggableautofechable, y ordenable.
Más adelante en la guía, veremos cómo integrar en nuestra aplicación este paquete. No te reprimas puedes explorar un capítulo sobre este tema en el recetario.

Conclusión

Hemos cubierto una serie de conceptos para hacer frente a los modelos de Doctrine 2. También vimos la definición de accesorios que nos proporciona una forma fácil de obtener datos adecuados para probar mientras desarrollamos nuestra aplicación.

A continuación vamos a ver cómo extender más el modelo añadiendo la entidad comentario. Vamos a empezar a construir la página inicial y crearemos un Repositorio personalizado para ello. También vamos a introducir el concepto de Migraciones de Doctrine y cómo interactuar con formularios en Doctrine 2 para permitir que se añadan comentarios a un blog.

© Copyright 2011, dsyph3r :: Traducido por Nacho Pacheco

Partes del artículo<< [Parte 2] Página de contacto: Validadores, formularios y correo electrónico[Parte 4] El modelo de comentarios: repositorios y migraciones de Doctrine >>

2 Responses to “[Parte 3] El modelo del Blog: Usando Doctrine 2 y accesorio”

  1. Manuel González

    Hola, ante todo enhorabuena por el tutorial (o la traducción más comentarios del mismo). Tengo un problema al tratar de cargar los accesorios, al lanzar por consola la carga con app/console doctrine:fixtures:load me devuelve el siguiente error:

    Fatal error: Class ‘SymfonyBundleDoctrineFixturesBundleDoctrineFixturesBundle’ not found in /var/www/Symblog/app/AppKernel.php on line 16

    $bundles = array(
    (…)
    new SymfonyBundleDoctrineFixturesBundleDoctrineFixturesBundle(),
    new SymfonyBundleDoctrineBundleDoctrineBundle(),
    new SymfonyBundleAsseticBundleAsseticBundle(),
    (…)
    }

    qué puede estar fallando?

    Gracias!

    Responder
  2. Aprendiz

    Ni el tutorial es mio ni la traducción tampoco jaja. Pero cuando lo estaba haciendo… la página desapareció y tuve que hacerlo algunos trozos por la cache.. pero menos mal que la mayoría lo había guardado..no sé porqué, la verdad jaja Yo soló perdí un poco de tiempo en pasarlo al blog :D

    Pues según parece es que no está cargando bien el bundle… en el auto load tiene que estar

    ...
    'Doctrine\Common\DataFixtures' => __DIR__.'/../vendor/doctrine-fixtures/
    lib',
    'Doctrine\Common' => __DIR__.'/../vendor/doctrine-common/lib',
    ...

    Importante que esté encima de common

    y luego en el appKernel

    $bundles= array(
    // ...
    new SymfonyBundleDoctrineFixturesBundleDoctrineFixturesBundle(),
    );

    En versiones 2.1… creo que sería new DoctrineBundleFixturesBundleDoctrineFixturesBundle()

    No se si te servirá :)

    Responder

Deja un comentario

  • (will not be published)


4 + 6 =