#jobeet

[vidium-blog]

Tutorial Symfony - Jobeet dia 10 - Formularios

The Form Framework

Los formularios forman parte de cualquier página web, generalmente suelen ser el punto más sensible a nivel de seguridad y errores, por lo que su correcta implementación es un punto crítico de cualquier web.

Symfony tiene un framework para manejarlos que se divide en tres partes:

Validación: tipos básicos como integer hasta complejos, como mail.

Widgets: Clases para mostrar distintos elementos HTML como inputs o selects...

Forms: conjunto de clases para manejar formularios, cada uno contiene validator+widget.

Forms

Cada formulario se configura en el método configure() mediante el uso de setValidators() y setWidgets().

Doctrine Forms

Como los formularios suelen manejar el CRUD del modelo de la base de datos, existen métodos para realizar la cargar de los mismos mediante un doctrine:build --forms, pero NO ES NECESARIO ahora, ya que está incluido al hacer doctrine:build --all.

Estos archivos se guardarán en lib/form/doctrine/*

Customizing the Job Form

Vamos a actualizar el formulario para crear una nueva oferta de trabajo "Post a Job", así que nos vamos a /lib/form/doctrine/JobeetJobForm.class.php.

PARTE 1: CREAR EL WIDGET

Por defecto aparecen todos los campos, así que vamos a ocultar los que no nos interesan mediante unset(), también podemos hacerlo al revés, es decir, indicando los que queremos mediante useFields()  que además nos permite indicar el orden de los elementos.

Esta segunda opción es mejor, ya que si añades algún campo a la bd controlas en todo momento los campos que verá el usuario.

PARTE 2: VALIDACIÓN

Ahora vamos a realizar la validación de los datos, el correo se valida como un string pero tenemos métodos para controlar que es un correo, también es recomendable concatenar validators con sfValidatorAnd(), de este modo ayudas al usuario y reduces errores.

Hecho esto vamos a controlar los horarios de trabajo, queremos que sea uno de los 3 valores predefinidos, para ello:

Nos vamos al modelo y creamos un atributo $types que puede tomar tres valores posibles.

Creamos un accesor para poder recuperarlos mediante un getTypes()

Volvemos al formulario y utilizamos sfWidgetFormChoice(), donde le indicamos que sea uno de los valores disponibles en getTypes()

Si queremos algún valor por defecto, tenemos que cambiarlo en el schema de la base de datos.

Symfony carga automáticamente un label asociado a cada campo, también podemos editar estos valores con $this->widgetSchema->setLabels()

Otro punto importante es la validación de ficheros mediante sfValidatorFile(), muy útil para:

Validar que el fichero tiene el tipo correcto (mime_types)

Dar un nombre único al archivo

Almacenar el fichero en la ruta dada en el action

Actualiza la columna logo en la base de datos con el nombre

The Form Template

Ahora que tenemos el formulario creado vamos a preparar la template, el formulario se renderiza a partir de la vista, es decir /apps/frontend/modules/job/templates/_form.php

Aquí añadimos las llamadas a los css y js en la cabecera, después necesitamos dos cosas:

form_tag_for() que genera una etiqueta <form> y se encarga de de hacer los métodos POST y PUT mediante los objetos que ya hemos visto de sf.

echo $form al mostrar esta variable hacemos un render de todos los widgets, sería lo mismo que hacer

foreach ($form as $widget){     echo $widget->renderRow() }

El objeto form tiene muchos métodos que conviene conocer para manejar el contenido, errores o etiquetas de los formularios.

The Form Action

El diagrama de flujo del formulario se puede sintetizar en esto,

Como ya tenemos las rutas creadas (ver día 5) vemos que antes de realizar cualquier petición al modelo, para modificar la base de datos, el controlador se encarga de procesar/validar el formulario a partir de los validators implementados.

También vemos que cuando se crea un nuevo trabajo, en executeNew(), el sistema manda un valor por defecto para Type, en este caso "full-time", esto también se podría hacer en el schema de la base de datos.

Protecting the Job Form with a Token

El token es un identificador único, este token se generará al crear un nuevo trabajo. Lo que buscamos es que aunque un usuario conozca una ruta, no pueda acceder a ella directamente, así protegemos la información de los ataques por fuerza bruta.

Seguimos los pasos que nos indican y editamos también el routing, ahora todas las URL tendrán la estructura:

http://jobeet.localhost.com/job/TOKEN/edit

The Preview Page

Vamos a añadir una pequeña barra de administración en la vista showSuccess, lo implementaremos mediante un partial (visto en los primeros días). Si no recuerdo mal, son pequeños includes de código que podemos reutilizar, en este caso _admin.php

Ahora cuando creamos un trabajo, tenemos que pulsar en "Publish" para que se publique y empiece el contador de expiración.

Job Activation and Publication

En vez de crear una nueva ruta, vamos a reutilizar "job:" sólo tenemos que modificar object_actions en el mismo fichero para enviarle un array con el resto de información.

Como sf maneja las peticiones como objetos podemos capturar ese put en el controlador actions.class.php

Por último vamos cerrar el acceso a las rutas de los trabajos, por un lado mediante el método checkCSRFProtection() que bloquea la mayoría de las inyecciones sql, luego para terminar comprobamos que no se muestren los trabajos que no estén activos.

Con esto ya hemos terminado

Final Thoughts

Los formularios cuentan con validators y widgets, los primeros deben ser anidados para acotar al máximo los valores de entrada, los segundos permiten pintar cualquier objeto de tipo input. 

Desde la clase form los vamos invocando para pintarlos en cualquier Vista, su validación se realiza dentro del mismo formulario antes de procesarlos.

[vidium-blog]

Tutorial Symfony - Jobeet dia 8 - Pruebas unitarias

Tests in symfony

A veces cuando añadimos una funcionalidad, refactorizamos una clase o simplemente hacemos un cambio, no tenemos ni puta idea si el programa se va a cascar. Symfony te permite realizar una serie de pruebas automatizadas que permiten mantener la ingridad del código, se dividen en:

Pruebas unitarias: prueban que cada método o función devuelve los resultados correctos, es independiente y prueba una cosa cada vez.

Pruebas funcionales: prueban el funcionamiento en conjunto, las veremos en el dia 9.

Todas estas pruebas se almacenan en /test/unit y /test/functional respectivamente.

Unit Tests

No hay que hacer pruebas a todo el software, lo mejor es empezar con los puntos críticos o donde encontremos bugs, nos permitirán mantener el código en una versión estable.

Para ello SF tiene un framework llamado lime para hacer pruebas, también puedes usar PHPunit.

The lime Testing Framework

Todas las pruebas de test empiezan igual, el número en lime_test() indica el número de pruebas que se van a realizar.

require_once dirname(__FILE__).'/../bootstrap/unit.php'; $t = new lime_test(1);

auque podríamos depurar todo con un método ok(), nos devuelve TRUE si lo cumple o FALSE en caso contrario, SF tiene un conjunto de métodos que nos ayuda a depurar o filtrar.

ok($test) Test a una condición y la pasa si es TRUE

is($value1, $value2) Compara dos valores y pasa si son iguales

isnt($value1, $value2) Compara dos valores y pasa si NO son iguales

like($string, $regexp) Prueba un string si cumple una expresión regular

unlike($string, $regexp) Prueba un string si NO cumple una expresión regular

is_deeply($array1, $array2) Compara dos arrays, pasa si son iguales

fail() Siempre falla, útil para test de excepciones

pass() Siempre pasa, útil para test de excepciones

skip($msg, $nb_tests) Cuenta el número de test, útil para condicionales

todo() Para test que todavía no están hechos ¿?

Por último hay un test llamado comment($msg) que muestra un mensaje pero no hace ningún test.

Running Unit Tests

Empezamos a crear el primer fichero de test, la nomenclatura es /test/unit/Nombre_CaseTest. CopyPaste y lo ejecutamos mediante:

$ php symfony test:unit Jobeet

Testing slugify

Durante el día 5 hemos creado unos parseadores que llamamos slugify para hacer las beautyURLs, su trabajo era:

pasaban todo a minúsculas

transformaban espacios y caracteres no-ASCII en guiones "-"

Seguimos los pasos, recuerda PRUEBA UNA ÚNICA COSA EN CADA TEST. Vamos a usar el método is() para comprobar distintas entradas y ver que formatea correctamente, todas las pruebas permiten un último parámetro de comentarios que nos sirve para documentar las pruebas.

Si queremos ser más papistas que el Papa, podemos bajarnos Xdebug para que nos diga si se han testeado todas las líneas del código, OJO los casos extremos los debemos crear nosotros, esto sólo cuenta líneas.

Yo paso por el momento... ;)

Adding Tests for new Features

Slug tiene algunos errores, por ejemplo si viene una cadena vacía, devuelve vacío y eso es caca cuando vayamos a crear una URL. Creamos primero el test y luego implementamos la funcionalidad, esta metodología se llama TDD.

Ahora añadimos la funcionalidad en la clase Jobeet y todo debe ir bien.

Adding Tests because of a Bug

Vamos a seguir mejorando el código, en este caso si un campo tiene sólo caracteres noASCII termina devolviendo la cadena vacía, creamos la prueba y modificamos el código.

Las vocales con acento también las cambia a guiones, utilizaremos la función iconv() este caso llamado "transliteration". No me queda muy claro donde tiene esta librería instalada pero funciona.

Doctrine Unit Tests

Es recomendable crear una bd dedicada para los test, SF puede utilizar una base de datos distinta para cada entorno por lo que crearemos una con el siguiente comando.

Database Configuration

$ php symfony configure:database --name=doctrine --class=sfDoctrineDatabase --env=test "mysql:host=localhost;dbname=jobeet_test" root PASSWORD

Puedes ver en /config/databases.yml como ha creado todo lo que necesita, pero todavía no tenemos ni la base de datos ni las tablas creadas. Para ello entro en phpmyadmin y creo jobeet_test. Luego cargo las tablas de desarrollo.

$ php symfony doctrine:insert-sql --env=test

La mayoría de los ficheros de configuración de la aplicación que están en YAML (databases, app, view, settings) permiten configurar los distintos entornos o utilizar el mismo con la clave all.

Test Data

Lo que hago a continuación es copiar los datos por defecto de /data/fixures a /text/fixures para que cuando haga el loadData(), más tarde pueda encontrarlos.

Testing JobeetJob

Ahora vamos a crear las pruebas unitarias en /test/bootstrap/Doctrine.php, en este archivo definiremos la cabecera muy parecida a la anterior, la conexión a la base de datos y la funcionalidad que vamos a testear.

Doctrine sólo conecta a la base de datos hasta que tiene querys para ejecutar, así que por el momento no podemos probar nada. Copiamos los archivos de /data/fixtures a /test/fixtures, ya que el método loadData() es capaz de coger archivos, directorios y todo su contenido.

CopyPaste del archivo creado y lo ejecutamos desde consola con

php test/bootstrap/Doctrine.php

Ahora hemos creado las tuplas dentro de las tablas, que estaban vacías. Si tienes un error porque no puede instanciar los objetos, puede ser que las tablas estén vacías. Nos queda añadir la funcionalidad a las pruebas que queremos realizar antes de ejecutarlas con:

./symfony test:unit JobeetJob

Recuerda que no hay que poner Test al final.

Test other Doctrine Classes

Puedo hacerlo para las otras clases pero por el momento no lo veo prioritario.

Unit Tests Harness

Podemos hacer un symfony test:unit que nos da la salida de todos los test de la aplicación juntos, muy profesional

Final Thoughts

Los test parecen una gilipollez para una primera versión, cuando un software empieza a coger cuerpo y necesitas sacar nuevas funcionalidades y módulos, los necesitarás para no estar probando lo mismo todo el tiempo. Recuerda que los ordenadores se crearon para automatizar tareas, no para dar más.

[vidium-blog]

Tutorial Symfony - Jobeet dia 7 - La página de categorias

Vamos a añadir una nueva funcionalidad a la aplicación, se trata de un nuevo módulo categoría, para casi todo en SF hay que seguir esta rutina:

Creas Rutas-> Creas Actions -> Creas Modelo -> Actualizas Vista

The Category Route

En routing es donde se demuestra si has pensado antes de picar código, estudia detenidamente los requisitos de tu aplicación, así como el comportamiento esperado y los parámetros que necesitas.

Vamos a crear una nueva ruta para categorías, todas las rutas posibles deberían estar contempladas en el momento que desactivamos el default, pero bueno estamos aprendiendo.

Creamos la ruta por copypaste... vamos con Actions y Modelo

The Category Link

Aunque el tutorial no sigue el orden estrictamente, en este punto modificamos:

VISTA indexSuccess.php para que pinte el enlace en la plantilla

CONTROLADOR no hay que cambiar nada en Actions ya que sigue siendo executeIndex()

MODELO refactorizamos la clase JobeetJob, ahora tenemos la query únicamente en addActiveJobsQuery() recuerda Dont Repeat Yourself (DRY) añadimos la lógica que necesitamos para la clase JobeetCategory.class.php

Job Category Module Creation

Crearemos ahora un módulo nuevo, podríamos añadirlo como un action dentro del módulo jobs, pero tiene más sentido crearlo para su propia página "categoría".

Para ello ejecutaremos

$php symfony generate:module frontend category

Para el carro... no es doctrine:generate-module? Sí, pero como no nos hace falta que doctrine nos cree nuevas clases para el modelo (sí, como ves podría haber sido un simple action) utilizamos genera:module a secas.

Update the Database

Actualizamos el esquema de la base de datos para añadir el campo "slug", ahora ya no necesitamos el método getSlug() de JobeetCategory. Por otro lado entramos en el controlador del nuevo módulo Category, vamos a editar el método executeShow() y nos creamos showSuccess.php.

Fijate como ya no vamos a redirigir a index, nos podemos cargar el archivo.

Partials

Este punto nos explica como podemos insertar trozos de plantilla que se repiten, creamos un archivo _PLANTILLA.php, ahora podemos invocarlo desde el helper include_partial().

<?php include_partial('job/list', array('jobs' => $jobs)) ?>

Esto es muy similar a usar un include() normal de PHP, la principal diferencia es que el helper puede tirar de caché por lo que será más rápido.

List Pagination

Symfony tiene una clase de paginación para Doctrine sfDoctrinePager, que contiene todos los métodos necesarios para su funcionamiento. Lo vamos a insertar en el controlador de Categorías, para que en vez de pasarle una lista de objetos a showSuccess() le envie el paginador.

Le indicamos la página 1 para cualquier caso donde no tenga variable, también definimos el número de elementos en app.yml . Por último facturizamos el modelo JobeetCategory.class, hacemos esto porque los 3 métodos de la clase son muy parecidos.

Sólo nos queda actualizar la vista, que va a tirar de los siguientes métodos del paginador: 

getResults(): Devuelve un array de objetos Doctrine para la página actual

getNbResults(): Devuelve el número total de resultados

haveToPaginate(): Devuelve TRUE si hay más de una página

getLinks(): Devuelve una lista de links de paginación

getPage(): Devuelve la página actual

getPreviousPage(): Devuelve la página anterior

getNextPage(): Devuelve el próximo número de página

getLastPage(): Devuelve el último número de página

La clase del paginador también incluye un iterator y un count() para poder operar con ellos.

Final Thoughts

Como hemos visto al principio, Creas Rutas-> Creas Actions -> Creas Modelo -> Actualizas Vista es la tónica general para crear una funcionalidad/módulo en SF. El paginador es una de las muchas clases de SF que nos hará el día a día más fácil, siempre y cuando leamos la documentación, recuerda DRY.

[vidium-blog]

Tutorial Symfony - Jobeet dia 6 - Más del modelo

Ya hemos visto cómo SF maneja el MVC y su estructura interna de ficheros, también como maneja las peticiones y el enrutamiento que conecta toda la aplicación. En el día 6 profundizaremos en el modelo de datos, utilizaremos doctrine para, a partir del código pregenerado, adaptarlo a las especificaciones del cliente y siguiendo el patrón MVC.

The Doctrine Query Object

Si volvemos a apps/frontend/modules/job/actions/actions.class.php veremos como nuestra aplicación hace un SELECT * (mediante el getTable) y luego ejecuta esa consulta con execute().

Vamos a hacer que devuelva los trabajos que estén activos, es decir, posteados/reactivados hace menos de 30 días. 

Debugging Doctrine generated SQL

Doctrine va a envolver todas las peticiones SQL, pero a veces conviene ver qué está ejecutando para depurar, en entorno de desarrollo (en adelante dev) SF almacenará en /log/frontend_dev.log todas estas querys. También está en la barra de desarrollo.

Existe un log para cada combinación de entorno y aplicación.

Vemos también la sintaxis de la condición 

WHERE j.created_at > ? (2008-11-08 01:13:35)

Nos vamos a parar en "?" esto es un string que se valida antes de entrar al motor de base de datos, gracias a este parse reducimos drásticamente las posibilidades de SQL Inyection.

Object Serialization

La serialización permite automatizar valores, en este caso cuando se crea un trabajo, expires_At se inicializa con fecha actual + 30 días. Para ello actualizaremos el método save() del modelo lib/model/doctrine/JobeetJob.class.php.

Después actualizamos actions para que sólo se muestren trabajos que expiren después de la fecha actual, por lo tanto no veremos ninguno.

More with Fixtures

El tutorial nos propone ahora sustituir los 2 trabajos que tenemos actualmente por 1 modificando data/fixures/jobs.yml. Como siempre cuidado con los espacios y vemos como parametriza createAt para pisar los valores por defecto, y como lo más importante, aplica expireAt gracias al polimorfismo del método save que hemos hecho en el modelo.

Custom Configuration

Como hemos metido 30 días a capón en el código, vamos a ser más elegantes y guardarlo en una variable global de la aplicación, cada aplicación tiene su propio archivo.

# apps/frontend/config/app.yml all:   active_days: 30

Así podremos acceder a ella con la clase sfConfig, esta clase también nos puede dar datos de configuración de la instalación de SF. Para este caso la sintaxis sería:

sfConfig::get('app_active_days')

Por último actualizaremos el método save() del modelo para que guarde en función de esta variable global. Te recomiendo jugar con el fixure y active_days, carga de nuevo los datos para empaparte bien de como funciona.

Refactoring

En MVC el modelo tiene la lógica de las querys, nosotros lo estamos metiendo en actions (que es el controlador). Refactorizar implica poner cada cosa en su sitio, tiene algunos buenos argumentos:

Primero por nomenclatura del MVC.

Hace el controlador más corto y fácil de leer.

getActiveJobs se vuelve reutilizable desde cualquier otro action del controlador.

El código del modelo se vuelve una unidad testeable.

Hacemos copypaste del tutorial para ordenar los resultados y seguimos.

Categories on the Homepage

Vamos a mostrar ahora varios listados según las categorías del trabajo, se mostrará un listado cuando tenga al menos un trabajo activo. Lo mejor es volver a coger el diagrama de la bd y seguir los pasos que nos detalla el tutorial.

Presta atención a cómo va añadiendo lógica en cada modelo y la invocamediante el action. Luego todo es pintar los objetos en la vista mediate dos foreach() anidados.

Limit the Results

Ahora pretendemos mostrar un máximo de 10 resultados por categoría, primero metemos la variable en código y luego vamos a hacer que la coja de las variables globales del sistema.

Modificamos la vista para que foreach() realice un máximo de 10 iteracciones

Dynamic Fixtures

Para poder ver los resultados, vamos a añadir más trabajos a /data/fixures/jobs.yml

En vez de hacer copypaste, Symfony nos permite insertar código PHP en el mismo YAML, recuerda que duplicar código es caca, ni siquiere para valores de prueba.

Gracias a dynamic fixtures ejecutamos un bucle que genera N instancias de jobs desde un mismo fichero YAML, así tendremos suficientes elementos para testear nuestro código.

Secure the Job Page

Vamos a impedir el acceso a trabajos caducados aunque el usuario conozca la URL, para ello editaremos el routing.yml y añadiremos una opción a la regla de show:

method_for_query: retrieveActiveJob

No tengo claro todavía como encuentra este método, creo que como el routing le marca el modelo, asume que es un método asociado a la clase de esa tabla pero no me queda muy claro... :S

Link to the Category Page

En el próximo capítulo se añadirán funcionalidades a la página de categorías, no dice nada nuevo.

Final Thoughts

Hemos visto dónde colocar las consultas a la bd para que generen los resultados que necesita nuestra aplicación, también hemos aplicado un polimorfismo al método save() para que guarde algunos valores automáticamente, hemos refactorizado y generado valores de prueba de forma masiva... un día completito

[vidium-blog]

Tutorial Symfony - Jobeet dia 5 - Routing

URLs

Cuando pulsamos sobre un trabajo en Jobeet, nos enseña una ruta extraña que nada tiene que ver con lo que esperamos en PHP.

  /job/show/id/1

Vamos a ver como SF desglosa este tipo de URLs, lo primero recordar que una URL es una dirección única de un recurso web, que en muchos casos, viene acompañada de datos necesarios para que nos devuelva el resultado que esperamos.

SF entiende que www.ruta.com?id=valor supone una vulnerabilidad ya que expone la estructura de nuestro sistema y compromete la seguridad. Su solución es un framework que "enruta" o redirige las URLs de entrada a unas URIs (ruta de los ficheros php) mediante comprobaciones como tipo de objeto, número de parámetros o permisos... toda una joya.

Routing Configuration

Este sistema está definido en routing.yml, que contiene un conjunto de rutas. Cada ruta está definida por un:

Nombre: identificador del mismo

Patrón: estructura de la ruta

Parámetros: parámetros que vienen en la misma

Cuando llega una petición, routing.yml intenta cuadrar esa URL con un recurso URI. Lo hace secuencialmente, el primero que encaja gana, por lo que hay que tener cuidado con el orden. Otro detalle es que en el patrón, a partir de /* define un conjunto de variables separadas por "/".

Estas rutas suelen ser utilizadas con el helper url_for() que hemos visto antes

url_for('job/show?id='.$job->getId()) url_for('@default?module=job&action=show&id='.$job->getId())

Como podeis ver, al usar la @ podemos marcar todos los valores, lógicamente es mucho más rapida ya que no tiene que comprobar en routing list y según la documentación es más flexible :p

Route Customizations

Empezamos a hacer algunos cambios, si estás en producción recuerda que si tocas el routing debes limpiar la caché, el comando es:

  php symfony cc

Recuerda que poner beauty URL es muy importante tanto para que los usuarios vean con más claridad a donde les lleva un enlace, donde están o lo más importante; influye en el SEO.

Requirements

Los requeriments permiten definir expresiones regulares, por ejemplo que una variable sea un integer o un objeto.

Route Class

También podemos definir el tipo de método GET, POST, HEAD, DELETE y PUT, ya hemos visto que symfony encapsula todas estas peticiones en objetos, podemos indicar que esperamos un método en concreto.

Object Route Class

Cuando he usado el url_for() para construir la URI me he quedado un poco decepcionado... muchos parámetros en un array pueden hacer que cometamos fallos, eso debió pensar el bueno de Fabian (si no sabes el día 5 quien ha inventado este fregao, hazte un sudo reboot)

Por eso se le ocurrió la clase sfDoctrineRoute, donde podemos indicar que esta ruta va a coger un objeto type:object (o un conjunto de ellos type:list) generado por el ORM. Ahora sólo tenemos que ir al helper para marcar ruta y objeto.

  url_for('job_show_user', $job)

A partir de aquí nos enseñan a crear un accesor para limpiar la URL, mostrando correctamente los caracteres extraños, el routing es muy potente y no sólo nos permite crear una URL a partir de un objeto, sino que además es capaz de encontrar un objeto a partir de una ruta.

Routing in Actions and Templates

En una plantilla, el helper url_for() convierte una URI interna en una URL externa. Existen otros helpers en SF que también toman una URI como argumento, por ejemplo link_to() que genera un tag <a>. Vamos a ver un par de ejemplos:

El código... <?php echo link_to($job->getPosition(), 'job_show_user', $job) ?>

Genera... <a href="/job/sensio-labs/paris-france/1/web-developer">Web Developer</a>

También es posible generar URLs absolutas... link_to($job->getPosition(), 'job_show_user', $job, true)

O generarlas desde un action con el método generateUrl()...  $this->redirect($this->generateUrl('job_show_user', $job)); 

Para terminar el punto, destacar que existen varios métodos para hace redirect(), redirectIf() y redirectUnless() que envian el request a otro action sin que lo tenga que procesar el navegador

Collection Route Class

La regla default está cogiendo todas las rutas por el momento, esto es bueno para ver algo funcional desde el principio pero carece de funcionalidad para el resto de métodos de la aplicación, digamos que es como un mockup.

Con los conocimientos actuales definiríamos una ruta/regla para cada función que quisieramos con la clase sfDoctrineRoute, si como en este caso, son los 7 métodos genéricos de CRUD (index, new, create, edit, update, delete, show) podemos usar sfDoctrineRouteCollection que nos lo generará automáticamente.

job:     class:   sfDoctrineRouteCollection     options: { model: JobeetJob }

Como los métodos DELETE y PUT no está admitidos por todos los navegadores, SF los parsea como puedes ver en el archivo apps/frontend/modules/job/templates/_form.php

Route Debugging

Puedes obtener información general del routing de la aplicación ejecutando

$ php symfony app:routes frontend

También puedes obtener información de un modulo en particular con 

$ php symfony app:routes frontend job_edit

Default Routes

La prueba de fuego, ya que hemos definido rutas para todos los action de la aplicación, ya no necesitamos la ruta default por lo que la comentamos, la aplicación debería seguir funcionando.

Final Thoughts

El archivo routing.yml sirve de semáforo para manejar las URLs públicas y transformarlas en URIs internas, o viceversa. También es el encargado de llamar a un action asociado y parsear parámetros.

Su comportamiento es como el resto de SF orientado a objetos, permitiéndonos controlar y validad el tipo de información que entra y sale en cada action.

[vidium-blog]

Tutorial Symfony - Jobeet dia 4 (Parte 3)

Sólo nos queda hablar de:

Slots

Error 404 en distintos entornos

Request y Response 

Los Slots

Ya hemos visto el patrón decorator, que es el que utiliza symfony. Además es posible insertar bloques o slots, que acompañan a la template, todo ello será renderizado/pintado mediante layout.php

Error 404

Symfony diferencia el entorno sobre el que trabajas, desarrollo o producción para ofrecer una vista con más información si es el desarrollador el que se enfrenta a un 404, por el contrario si es un usuario en producción devuelve una página más corporativa.

Todo ello se puede controlar por objetos, en este tutorial te redirige a no ser que tenga un objeto job.

Request y Response

Toda plataforma cliente servidor se comunica mediante peticiones Request y respuestas Response. Symfony encapsula en sfWebRequest y sfWebResponse.

El objetivo es utilizar el mismo paradigma todo el tiempo, facilitando además el trabajo al desarrollador, ya que siempre será más fácil emular o construir este tipo de elementos para las pruebas.

Con esto terminamos el dia 4 de symfony que para mi ha sido el más espeso... (lo que me queda)

[vidium-blog]

Tutorial Symfony - Jobeet dia 4 (Parte 2)

En Symfony, dentro de cada módulo hay un fichero llamado actions.class.php, este es el controlador. Tiene un conjunto de métodos que enrutan la información que ÉL obtiene del modelo.

Symfony asocia los métodos del controlador que empiecen por execute con las vistas, por ejemplo executeIndex.php intentará  ejecutarlo con la vistaindexSuccess.php

Hablando en plata, este actions habla con doctrine para pedirle lo que sea de la base de datos, lo procesa y se lo manda a la vista/template que tenga de ruta, como por ejemplo indexSuccess.php.

Por lo demás sólo falta mencionar como invoca a un helper que no está cargado en la vista de Show, 

<?php use_helper('Text') ?>

y como enlaza a otra URL (en este caso Show) para que el controlador vuelva a enrutar y pase los parámetros mediante 

<?php echo url_for('job/edit?id='.$job->getId()) ?>

Dejamos para el último post los Slots

[vidium-blog]

Tutorial Symfony - Jobeet dia 4 (Parte 1)

El día 4 empieza con la explicación del

MVC - Modelo Vista Controlador

No nos pararemos mucho en ellos ya que lo explican muy bien tanto en la web como en wikipedia, nos quedamos con:

Modelo: clases de lógica con la base de datos está en lib/model/

Vista: plantilla de PHP, carga imagenes, css y js, está en templates/ 

Controlador: solicita y enruta datos del modelo para que los pinte la vista suele ser index.php y frontend.php. Pasan peticiones a los actions y estos a su vez a los modules

El layout

SF utiliza el patrón decorator para renderizar las páginas, es algo así:

básicamente está en /nombreAplicación/templates/layout.php es un archivo que llama a funciones y referencias en PHP.

Hoja de estilos, imagenes y JS

Van en la carpeta web/, por defecto al generar un módulo se crean sus propias subcarpetas. Su llamada se hace desde el layout (mirar en header) con include_stylesheets() ESTA FUNCIÓN ES UN HELPER

Los helper toman parámetros y devuelven HTML, en este caso coge datos de nombreAplicación/config/view.yml para en este caso devolver el html necesario para las hojas de estilos.

Por regla general, siempre que podamos hacer un view.yml para configurar un módulo también podemos llamar al helper con parámetros use_stylesheet('main.css')

Resumiendo

Para muchos archivos de configuración, los valores pueden ser descritos en distintos niveles:

La configuración por defecto está en el framewrok.

La configuración local en config/

La local de aplicación es apps/APP/config

Local de aplicación restringida a un módulo en apps/APP/modules/MODULE/config/

En el siguiente post veremos como el controlador se comunica con la vista para generar la página resultante