Por defecto Symfony no muestra el archivo que hace de controlador (index.php, frontend_dev.php, etc) para cambiarlo vamos al archivo settings.yml aquí podemos indicar que no se muestre el nombre del controlador de la siguiente manera: [codesyntax lang=»text»] prod: .settings: no_script_name: off [/codesyntax] Hiperenlaces, botones y formularios [codesyntax lang=»php» title=»Los helpers de enlaces aceptan opciones
Continuo con el libro de Symfony 1.4 en esta ocasión toca el enrutamiento. Normalmente las urls que escribimos son así: http://www.ejemplo.com/web/galeria/album.php?nombre=mis%20vacaciones http://www.ejemplo.com/web/weblog/publico/post/listado.php http://www.ejemplo.com/web/general/contenido/pagina.php?nombre=sobre%20nosotros Y deberían ser así: http://www.ejemplo.com/articulos/economia/2006/sectores-actividad.html Principalmente porque son mucho más legibles para los usuarios y buscadores, y además evitamos mostrar información a un posible atacante. El sistema de enrutamiento utiliza un archivo
CONEXIONES A LA BASE DE DATOS [codesyntax lang=»text» title=»Conexión básica»] > php symfony configure:database "mysql://login:password@localhost/blog" [/codesyntax] [codesyntax lang=»text» title=»Definiendo una conexión para un entorno concreto de la aplicación»] > php symfony --env=prod configure:database "mysql://login:password@localhost/blog" [/codesyntax] [codesyntax lang=»text» title=»Definiendo una conexión para una aplicación concreta»] > php symfony --app=frontend configure:database "mysql://login:password@localhost/blog" [/codesyntax] [codesyntax lang=»text» title=»Definiendo
Cuando Symfony construye el modelo, crea una clase de objeto base para cada una de las tablas definidas en schema.yml. Cada una de estas clases contiene una serie de constructores y accesores por defecto en función de la definición de cada columna: los métodos new, getXXX() y setXXX() (donde XXX es el nombre del campo)
Más de uno conocerá esas imágenes o PDFs que, de forma resumida, muestran todos los métodos y funciones de los lenguajes de programación o de frameworks. Con Symfony eso no es diferente, además de ser muy útil en las primeras etapas de aprendizaje. Os dejo el link: http://trac.symfony-project.org/wiki/CheatSheets ¡Qué lo disfrutéis!
Las bases de datos son relacionales. PHP 5 y Symfony están orientados a objetos. Para acceder de forma efectiva a la base de datos desde un contexto orientado a objetos, es necesaria una interfaz que traduzca la lógica de los objetos a la lógica relacional. Esta interfaz se llama ORM (object-relational mapping) o «mapeo de
Supongo que ya sabrás de lo que voy a hablar, sí, codificación de caracteres y el jodío de Dreamweaver. Te cuento: Estoy haciendo algunas pruebas con Symfony y su sistema de internacionalización ( I18N ), y para ello he hecho que el charset que muestre la plantilla sea utf-8 (además de las tablas de la
SEGURIDAD DE LA ACCIÓN Con Symfony podemos controlar quién puede acceder a una acción concreta, utilizando para ello las herramientas de identificación de usuarios que el framework nos provee. Una acción segura sólo podrá ser ejecutada por un usuario registrado y que tenga la acreditación para ello. Las acciones seguras requieren que los usuarios estén
Sí, sigo dándole caña a Symfony… y cometiendo errores de novato xD. Para ir probando Symfony con un proyecto real, he decidido utilizar una base de datos ya existente para generar una nueva versión del proyecto anterior, y como ya sabrás para que Symfony (bueno, en este caso Propel) genere las clases necesarias para trabajar
La versión 1.4 de Symfony utiliza por defecto como ORM a Doctrine, ya que tiene mejor rendimiento, pero las prácticas de Symfony como por ejemplo Jobeet utiliza Propel. Asi que, para poder utilizar este ORM hay que generar la aplicación con el parámetro –orm, tal como sigue: symfony generate:project mi_proyecto –orm=Propel De esta forma, Propel,
