Estas en: Home > configuracion

Entradas etiquetadas con configuracion

Integración continua: Automatizando la creación de proyectos WordPress, Drupal, Symfony, etc. (II)

0

En el post anterior hemos actualizado el script que crea los repositorios, para poder añadirle unas cuantas acciones para automatizar la creación del proyecto (creación de directorios, directorios ignorados, etc.). Ahora vamos a desarrollar la segunda parte, que consistirá en la automatización de la instalación del cms o framework elegido.

(más…)

Integración continua: Instalando y configurando Redmine

0

¿Qué es Redmine?

Redmine es una herramienta de gestión de proyectos, nos permite mantener un control de las tareas y errores a solucionar en ellos. Esta herramienta nos permite organizar los proyectos por versiones, o por springs si utilizas alguna metodología ágil. Dispone de gráficos Grantt, wiki, acceso al repositorio del proyecto, etc.; muchísimas características que nos facilitan el día a día en el desarrollo de proyectos.

Instalando Redmine

La instalación de Redmine es bastante sencilla, utiliza el siguiente comando:

apt−get install redmine redmine−mysql libapache2−mod−passenger

Una vez instalado y configurado creamos una carpeta en /var/www llamada redmine:

mkdir /var/www/redmine

A continuación, creamos un enlace simbólico con el contenido que se mostrará en el navegador:

ln −s /usr/share/redmine/public /var/www/redmine

Accediendo a Redmine desde un subdominio

Ahora configuraremos un subdominio para poder acceder a Redmine.

Comprueba que tienes activado el módulo passenger en apache2:

a2enmod passenger

Instala «bundle», una gema de Ruby:

gem install bundle

Da permisos al usuario www-data:

usermod −aG root www−data
chmod 775 −R /usr/share/redmine

Modifica el archivo /etc/apache2/mods-available/passenger.conf añadiendo la siguiente línea:

PassengerDefaultUser www−data

Crea el VirtualHost en /etc/apache2/sites-available, con el siguiente contenido:

 *:80>
        ServerName redmine.ic.net

        DocumentRoot /var/www/redmine
         /var/www/redmine>
                AllowOverride all
                Options −MultiViews
                PassengerResolveSymlinksInDocumentRoot on
        

Reinicia apache:

/etc/init.d/apache2 restart

Al igual que hicimos con Jenkins, será necesario que modifiques tu archivos hosts y añadas la siguiente línea:

192.168.1.40 redmine.ic.net

Sustituye la IP por la tuya.

Ahora, si escribes la dirección de Redmine en tu navegador podrás acceder a tu gestor de proyectos. El usuario para el administrador es «admin» y su contraseña «admin».

A partir de aquí, es cosa tuya. Crea algunos proyectos, añade algunas versiones, tareas, errores, etc.

Integración continua: primeros pasos

0

Ya expliqué la semana pasada qué era eso de la integración continua, pues bien, ahora toca dar los primeros pasos. Obviamente necesitamos un ordenador que haga de servidor, una máquina virtual, o bien un servidor de verdad si lo que pretendes es utilizar de forma profesional.

Como sistema operativo para esta guía utilizaré Ubuntu 14.04. Tú puedes usar el que quieras pero tal vez te resulte más complicado encontrar algún software, con lo que tendrás que investigar más.

El hardware a usar dependerá de las necesidades que tengas, o para lo que quieras un servidor de integración continua. En mi caso utilizo un pc de gama baja con micro AMD, 8 GB de RAM, sin teclado, ratón, ni monitor (y por tanto sin escritorio gráfico), y con una tarjeta WiFi para conectar a internet. Y esto, para mí, es suficiente. Si lo fueses a usar en un grupo de desarrollo, lo mejor es usar un VPS o un servidor dedicado, ya que mejorará en gran medida el rendimiento.

Ya tenemos el hardware listo y nuestro sistema operativo está instalado, por tanto vamos a iniciar los primeros pasos para crear nuestro servidor de integración continua.

(más…)

Integración continua: Introducción

0

Supongo que os preguntaréis qué es eso de la integración continua, pues bien, os explico: se considera Integración Continua al conjunto de metodologías y procesos que se ejecutan durante el desarrollo de un proyecto de programación, con la diferencia de que estos procesos están centralizados y automatizados, lo que permite ejecutarlos cada pocas horas.

Dentro de los procesos automatizados se encuentran la descarga de los repositorios, la comprobación de los estándares de codificación, la ejecución de los test unitarios, la actualización de la base de datos, el despliegue al servidor de producción, etc. Cualquier proceso que se ejecute durante el desarrollo de un proyecto se puede integrar en este sistema.

Esta forma de trabajar nos permite a los desarrolladores detectar, antes de poner en producción el proyecto, posibles errores o ineficiencias, pudiendo solucionarlos y mejorando con ello la calidad del software que generamos.

Sirva este pequeño artículo como introducción a esta nueva sección del blog, ya que durante las próximas semanas iré publicando nuevos artículos para que podáis montar vuestro propio servidor de integración continua, me centraré en la automatización de procesos en proyectos PHP, ya sean basados en Frameworks (Symfony, Zend, etc.), CMS (WordPress, PrestaShop, etc.) o creados desde cero, aunque es muy posible que muchas cosas de las que os explique podáis utilizarlas para otros lenguajes de programación. Os explicaré tanto la instalación del software necesario como su configuración, además de como unir todo el software para que se ejecute de forma automática.

De momento os dejo con varios links para que le vayáis echando un ojo a eso de la Integración Continua:

– http://es.wikipedia.org/wiki/Integraci%C3%B3n_continua

Desarrollo PHP avanzado

Optimizar el servidor web Apache

1

Tenía intención de crear un post explicando la optimización de Apache, pero la verdad es que en la red ya existe bastante información al respecto por tanto os dejo dos links, uno explicando cada uno de los parámetros que se pueden modificar en el archivo httpd.conf de Apache y el otro con algunos ejemplos de optimización:   – Definición de parámetros: http://www.codenb.com/optimizar-apache-16/ – Ejemplos: http://www.forosdelweb.com/f58/recetas-para-configuracion-apache-404961/

#symfony, I18N, UTF-8 y Dreamweaver

0

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 BD y las conexiones desde y hacía la BD), lo curioso es que cuando he ido a verlo en el navegador el resultado me aparecía con chinos (unos cuadrados (aunque pueden ser otros símbolos) que sustituyen a las letras con tilde), total que me he tirado todo el día dándole vueltas al tema, y el problema lo tenía en Dreamweaver que, por defecto, guarda los archivos en «Europeo occidental» y no en utf-8.

Te explico todo lo que he modificado en el proyecto de Symfony, por si te pasa algo parecido puedas comparar. Con esta configuración que te voy a mostrar el sistema de internacionalización de Symfony funciona al 100%:

Antes de nada te informo que esto está pensado para Symfony 1.4, versiones superiores o inferiores pueden necesitar una configuración distinta. Cuando hablo de Dreamweaver me refiero a la versión CS3, aunque muy probablemente algo parecido haya en versiones superiores.

settings.yml

Doy por hecho que ya has creado el proyecto, al menos una aplicación y un módulo con el que hacer pruebas. Nos vamos al archivo settings.yml de la app y añadimos:

 

[codesyntax lang=»text» title=»Configuración del archivo settings.yml para internacionalización»]

all:
  .settings:

    # Indicamos la cultura por defecto
    # Aquí poned la que os interese
    default_culture: es_ES   

    # Indicamos la codificación de caracteres
    charset: utf-8

    # Esto lo dejo a tu elección
    # Puedes escribir esta línea para que el helper I18N esté
    # en todas las plantillas de forma global
    # Lo bueno de usar esta opción es que puedes añadir
    # más helpers:
    # standard_helpers: [I18N,text, etc]
    standard_helpers: [I18N]  

    # O puedes escribir esta otra línea, pero
    # en cada una de las plantillas tendrás que incluir
    # al prinicipio <?php use_helper('I18N') ?>
    # la decisión es tuya
    i18n: true

[/codesyntax]

 

routing.yml

Modificamos este archivo para indicar el módulo que se mostrará como página de inicio (homepage):

 

[codesyntax lang=»text»]

# Esto es lo que está por defecto
homepage:
  url:   /
  param: { module: default, action: index }

# Lo único que cambio es el nombre del módulo, que en mi caso es 'login'
homepage:
  url:   /
  param: { module: login, action: index }

[/codesyntax]

 

 

view.yml

Este archivo creo que no hacia falta modificarlo para la internacionalización, pero por si acaso:

[codesyntax lang=»text»]

  metas:
    language:     es

[/codesyntax]

 

indexSuccess.php del módulo

Añadimos el texto que vamos a probar:

[codesyntax lang=»php»]

// No voy a poner todo el código que tengo en mi plantilla
// así que pongo solo un ejemplo

<?php echo __('Hola Mundo!') ?>

// Esto te mostrará el texto en español

[/codesyntax]

Bien, como le hemos dado el valor «es_ES» a «default_culture«, Symfony no mostrará ninguna traducción sino el valor que le hemos indicado en la plantilla. Para hacer una prueba en condiciones vamos a modificar la cultura de un usuario a «en_EN«, esto mantendrá la cultura de todo el proyecto como «es_ES«.

 

actions.class.php del módulo

En la acción Index escribimos lo siguiente:

[codesyntax lang=»php»]

class loginActions extends sfActions
{
 /**
  * Executes index action
  *
  * @param sfRequest $request A request object
  */
  public function executeIndex(sfWebRequest $request)
  {

        // Esta línea cambiará la cultura SÓLO para el usuario
	$this -> getUser() -> setCulture('en_EN');

	return sfView::SUCCESS;
  }
}

[/codesyntax]

Obviamente nos falta crear el archivo que le indicará a Symfony el texto que debe utilizar para su sustitución. A ello voy:

 

english.en.xml

Este archivo se guarda en la carpeta «i18n» de la app, aunque también puedes crear la carpeta dentro del módulo y guardar el archivo allí. Este archivo tiene un formato especial que se debe mantener:

[codesyntax lang=»text»]

<?xml version="1.0" encoding="utf-8"?>
<xliff version="1.0">
  <file orginal="global" source-language="en_EN" datatype="plaintext">
    <body>
      <trans-unit id="1">
        <source>Hola Mundo!</source>
        <target>Hello World!</target>
      </trans-unit>
      <trans-unit id="2">
        <source>soy un texto</source>
        <target>I'm a text</target>
      </trans-unit>
      <trans-unit id="3">
        <source>Adiós</source>
        <target>Bye</target>
      </trans-unit>
    </body>
  </file>
</xliff>

[/codesyntax]

Cosas importantes respecto de este archivo:

  • Le puedes poner cualquier nombre pero debe acabar en *.culture.xml, por ejemplo: login.en.xml, registro.en.xml, administracion.fr.xml, comentario.it.xml.
  • También se puede poner la cultura completa, es decir, en vez de solo *.en.xml puedes nombrarlo como *.en_EN.xml.
  • El parámetro «source-language» siempre debe indicar la cultura que se va a traducir, en este caso es el ingles (en_EN).
  • Cada texto a traducir está dentro de la etiqueta <trans-unit>, que tiene el atributo id, pues bien, cada frase a traducir debe aumentar el id ( 1,2,3,4,5….500 etc)
  • No es necesario que todas las frases estén en un solo archivo, puede haber varios archivos con textos diferentes, por ejemplo, para el menú, la cabecera, el pie de página, etc.,. Importante: aunque sean archivos para idiomas diferentes el nombre del archivo siempre debe ser el mismo, variando, eso sí, la cultura.

Una vez guardado el archivo volvemos al indexSuccess.php y lo modificamos para que quede tal que así;

[codesyntax lang=»php»]

// No voy a poner todo el código que tengo en mi plantilla
// así que pongo solo un ejemplo

<?php echo __('Hola Mundo!', null, 'login') ?>

// Ahora mostrará el texto que corresponda con la cultura del usuario
// Además lo buscará en un archivo concreto en este caso login.en.xml

[/codesyntax]

Y así se internacionaliza un proyecto Symfony. Ahora el problemita de Dreamweaver:

El bicho, (por llamarlo de alguna manera) tiene una opción para abrir archivos que no indiquen su codificación. Normalmente está en «Europeo occidental» y debería estar en «Unicode (utf-8)«. Para cambiarlo accedemos al menú «Edición -> Preferencias…» y en «Nuevo documento» busca un desplegable que ponga «Codificación pred.«; ahí elige «Unicode (utf-8)«, activa la casilla que dice «Utilizar al abarir archivos existentes que no indiquen su codificación» y en el desplegable de abajo (Formulario de normas Unicode) selecciona «C (descomposición de compatibilidad seguida de composición canónica)«. Pulsa aceptar y prueba el en navegador.

Tal vez tengas que limpiar la cache de Symfony para ello solo tienes que escribir en la consola (que debe apuntar a la carpeta donde tienes el proyecto) symfony cc o php symfony cc.

Si sigue fallando, abre el archivo indexSuccess.php del módulo con el bloc de notas, y sin modificar nada, vete a Archivo -> Guardar como… , ahí podrás elegir la codificación, en nuestro caso, utf-8, y para evitar que se guarde como un archivo .txt elige «Todos los archivos» y así se guardará en php. Vuelve a limpiar la caché y vuelve a probar, ahora sí te debería funcionar bien.

Symfony: El controlador (III)

0

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 autenticados.
  • Las credenciales son privilegios de seguridad agrupados bajo un nombre y que permiten organizar la seguridad en grupos.

[codesyntax lang=»text» title=»Estableciendo restricciones de acceso, en apps/frontend/modules/mimodulo/config/security.yml»]

ver:
  is_secure:   off       # Todos los usuarios pueden ejecutar la acción "ver"

modificar:
  is_secure:   on        # La acción "modificar" es sólo para usuarios autenticados

borrar:
  is_secure:   on        # Sólo para usuarios autenticados
  credentials: admin     # Con credencial "admin"

all:
  is_secure:  off        # off es el valor por defecto

[/codesyntax]

 

Lo que sucede cuando un usuario trata de acceder una acción restringida depende de sus credenciales:

  • Si el usuario está autenticado y tiene las credenciales apropiadas, entonces la acción se ejecuta.
  • Si el usuario no está autenticado, es redireccionado a la acción de login.
  • Si el usuario está autenticado, pero no posee las credenciales apropiadas, será redirigido a la acción segura por defecto.

Las páginas login y secure son bastante simples, por lo que seguramente será necesario personalizarlas. Se puede configurar que acciones se ejecutan en caso de no disponer de suficientes privilegios en el archivo settings.yml de la aplicación cambiando el valor de las propiedades:

[codesyntax lang=»text» title=»Las acciones de seguridad por defecto se definen en apps/frontend/config/settings.yml»]

all:
  .actions:
    login_module:  default
    login_action:  login

    secure_module: default
    secure_action: secure

[/codesyntax]

 

OTORGANDO ACCESO

Los métodos utilizados para permitir acceso a una acción segura se encuentran en el objeto sfUser. El estado identificado se establece con setAuthenticated() y se puede comprobar con isAuthenticated():

[codesyntax lang=»php» title=»Estableciendo el estado de autenticación del usuario»]

<?php

class miCuentaActions extends sfActions
{
  public function executeLogin($peticion)
  {
    if ($peticion->getParameter('login') == 'valor')
    {
      $this->getUser()->setAuthenticated(true);
    }
  }

  public function executeLogout()
  {
    $this->getUser()->setAuthenticated(false);
  }
}

[/codesyntax]

Las credenciales son un poco más complejas de tratar, ya que se pueden verificar, agregar, quitar y borrar:

[codesyntax lang=»php»]

<?php

class miCuentaActions extends sfActions
{
  public function executeEjemploDeCredenciales()
  {
    $usuario = $this->getUser();

    // Agrega una o más credenciales
    $usuario->addCredential('parametro');
    $usuario->addCredentials('parametro', 'valor');

    // Verifica si el usuario tiene una credencial
    echo $usuario->hasCredential('parametro');                         => true

    // Verifica si un usuario tiene una de las credenciales
    echo $usuario->hasCredential(array('parametro', 'valor'));         => true

    // Verifica si el usuario tiene ambas credenciales
    echo $usuario->hasCredential(array('parametro', 'valor'), true);   => true

    // Quitar una credencial
    $usuario->removeCredential('parametro');
    echo $usuario->hasCredential('parametro');                         => false

    // Elimina todas las credenciales (útil en el proceso de logout)
    $usuario->clearCredentials();
    echo $usuario->hasCredential('valor');                             => false
  }
}

[/codesyntax]

Las credenciales se pueden utilizar también para mostrar contenido autenticado en una plantilla:

[codesyntax lang=»php»]

<?php

<ul>
  <li><?php echo link_to('seccion1', 'content/seccion1') ?></li>
  <li><?php echo link_to('seccion2', 'content/seccion2') ?></li>
  <?php if ($sf_user->hasCredential('seccion3')): ?>
  <li><?php echo link_to('seccion3', 'content/seccion3') ?></li>
  <?php endif; ?>
</ul>

[/codesyntax]

 

CREDENCIALES COMPLEJAS

a sintaxis YAML utilizada en el archivo security.yml permite restringir el acceso a usuarios que tienen una combinación de credenciales, usando asociaciones de tipo AND y OR. Con estas combinaciones, se pueden definir flujos de trabajo y sistemas de manejo de privilegios muy complejos — como por ejemplo, un sistema de gestión de contenidos (CMS) cuya parte de gestión sea accesible solo a usuarios con credencial admin, donde los artículos pueden ser editados solo por usuarios con credenciales de editor y publicados solo por aquellos que tienen credencial de publisher:

[codesyntax lang=»text»]

editarArticulo:
  credentials: [ admin, editor ]              # admin AND editor

publicarArticulo:
  credentials: [ admin, publisher ]           # admin AND publisher

gestionUsuarios:
  credentials: [[ admin, superuser ]]         # admin OR superuser

[/codesyntax]

Cada vez que se añade un nuevo nivel de corchetes, la lógica cambia entre AND y OR. Así que se pueden crear combinaciones muy complejas de credenciales, como la siguiente:

[codesyntax lang=»text»]

credentials: [[root, [supplier, [owner, quasiowner]], accounts]]
             # root OR (supplier AND (owner OR quasiowner)) OR accounts

[/codesyntax]

 

CONFIGURACIÓN DEL MÓDULO

Algunas características de los módulos dependen de la configuración. Para modificarlas, se debe crear un archivo module.yml en el directorio config/ y se deben definir parámetros para cada entorno (o en la sección all: para todos los entornos).

[codesyntax lang=»text» title=»Configuración del módulo, en apps/frontend/modules/mimodulo/config/module.yml»]

all:                  # Para todos los entornos
  enabled:            true
  is_internal:        false
  view_class:         sfPHP
  partial_view_class: sf

[/codesyntax]

El parámetro enabled permite desactivar todas las acciones en un módulo. En ese caso, todas las acciones se redireccionan a la acción module_disabled_module/module_disabled_action (tal y como se define en el archivo settings.yml).

El parámetro is_internal permite restringir la ejecución de todas las acciones de un módulo a llamadas internas. Esto es útil por ejemplo para acciones de envío de correos electrónicos que se deben llamar desde otras acciones para enviar mensajes de e-mail, pero que no se deben llamar desde el exterior.

El parámetro view_class define la clase de la vista. Debe heredar de sfView. Sobreescribir este valor permite utilizar otros sistemas de generación de vistas con otros motores de plantillas, como por ejemplo Smarty.

El parámetro partial_view_class define la clase de la vista que se emplea para los elementos parciales de este módulo. La clase indicada debe heredar de sfPartialView.

Symfony: La vista (III), configuración de la vista

0

La vista en Symfony está dividida en dos partas:

  • Las plantillas (fragmentos de código): donde se recoge el resultado de la acción.
  • El resto: etiquetas meta, título de la página, archivos js y css, acciones que necesitan un layout personalizado (ventanas emergentes, publi) y las acciones que no necesitan layout alguno como las acciones para ajax.

Para modificar todo lo del segundo punto, que en general, podríamos considerar las cabeceras de la página, Symfony utiliza dos formas: a través del archivo de configuración view.yml o a través del objeto sfResponse para poder modificar las cabeceras de forma dinámica desde las acciones.

Si un mismo parámetro de configuración se establece mediante el objeto sfResponse y mediante el archivo view.yml, tiene preferencia el valor establecido mediante el objeto sfResponse.

EL ARCHIVO view.yml

editSuccess:
metas:
title: Edita tu perfil

editError:
metas:
title: Error en la edición del perfil

all:
stylesheets: [mi_estilo]
metas:
title: Mi sitio web

Esto anterior es la configuración de la vista de un módulo. Por defecto el archivo no existe y tendrías que crearlo y guardarlo dentro de la carpeta del módulo así: mimodulo/config/view.yml. Como puedes ver hay tres apartados:

  • editSuccess: Esta configuración se utilizará cuando la acción edit devuelva una respuesta igual a sfView::SUCCESS (o no devuelve nada, ya que es el valor devuelto por defecto).
  • editError: Esta configuración se utilizará cuando la acción edit devulva una respuesta igual a sfView::ERROR.
  • all: Esta es la configuración por defecto del módulo.

Para que veas la configuración en cascada de una aplicación en Symfony mira esto:

  • En apps/miaplicacion/modules/mimodulo/config/view.yml, las definiciones de cada vista solo se aplican a una vista y además sus valores tienen preferencia sobre las opciones generales del módulo.
  • En apps/miaplicacion/modules/mimodulo/config/view.yml, las definiciones bajo all: se aplican a todas las acciones del módulo y tienen preferencia sobre las definiciones de la aplicación.
  • En apps/miaplicacion/config/view.yml, las definiciones bajo default: se aplican a todos los módulos y todas las acciones de la aplicación.

Supongo que te estarás preguntando dónde se definen las cabeceras de la página, pues bien, estás se defienen en el archivo view.yml de la aplicación.

default:
http_metas:
content-type: text/html
metas:
title: symfony project
robots: index, follow
description: symfony project
keywords: symfony, project
language: en
stylesheets: [main]
javascripts: [ ]

has_layout: on
layout: layout

Más adelante explico las distintas opciones de la configuración de la vista. Antes veamos la segunda forma de configurar la vista.

EL OBJETO sfResponse

Aunque el objeto sfResponse pertenece a la vista, se puede acceder a él a través de la acción mediante el método getResponse. Algunos métodos que se utilizan habitualmente:

class mimoduloActions extends sfActions
{
public function executeIndex()
{
$respuesta = $this->getResponse();

// Cabeceras HTTP
$respuesta->setContentType(‘text/xml’);
$respuesta->setHttpHeader(‘Content-Language’, ‘en’);
$respuesta->setStatusCode(403);
$respuesta->addVaryHttpHeader(‘Accept-Language’);
$respuesta->addCacheControlHttpHeader(‘no-cache’);

// Cookies
$respuesta->setCookie($nombre, $contenido, $expiracion, $ruta, $dominio);

// Atributos Meta y cabecera de la página
$respuesta->addMeta(‘robots’, ‘NONE’);
$respuesta->addMeta(‘keywords’, ‘palabra1 palabra2’);
$respuesta->setTitle(‘Mi Página de Ejemplo’);
$respuesta->addStyleSheet(‘mi_archivo_css’);
$respuesta->addJavaScript(‘mi_archivo_javascript’); } }

Los métodos setter mostrados anteriormente que permiten dar un valor a la propiedad, también disponen de un método getter que devuelven el valor de la propiedad.

OPCIONES DE CONFIGURACIÓN DE LA VISTA

Copypasteo la introducción de esta sección del libro de Symfony:

Puede que hayas observador que existen 2 tipos diferentes de opciones para la configuración de la vista:

  • Las opciones que tienen un único valor (el valor es una cadena de texto en el archivo view.yml y el objeto respuesta utiliza un método set para ellas)
  • Las opciones que tienen múltiples valores (el archivo view.yml utiliza arrays para almacenar los valores y el objeto respuesta utiliza métodos de tipo add)

Hay que tener en cuenta por tanto que la configuración en cascada va sobrescribiendo los valores de las opciones de un solo valor y va añadiendo valores a las opciones que permiten valores múltiples. Este comportamiento se entiende mejor a medida que se avanza en este capítulo.

ETIQUETAS META

Las etiquetas <meta> se pueden definir dentro de las claves http_metas: y metas: en el archivo view.yml, o utilizando los métodos addHttpMeta() y addMeta() del objeto sfResponse dentro de la acción:

http_metas:
cache-control: public
metas:
description: Página sobre economía en Francia
keywords: economía, Francia

$this->getResponse()->addHttpMeta(‘cache-control’, ‘public’);
$this->getResponse()->addMeta(‘description’, ‘Página sobre economía en Francia’);
$this->getResponse()->addMeta(‘keywords’, ‘economía, Francia’);

Para las etiquetas <meta>, se puede añadir al método addHttpMeta() (y también a setHttpHeader()) un tercer parámetro con un valor de false para que añadan el valor indicado al valor que ya existía y así no lo reemplacen.

$this->getResponse()->addHttpMeta(‘accept-language’, ‘en’);
$this->getResponse()->addHttpMeta(‘accept-language’, ‘fr’, false);
echo $this->getResponse()->getHttpHeader(‘accept-language’);
=> ‘en, fr’

Para añadir las etiquetas <meta> en la página que se envía al usuario, se deben utilizar los helpers include_http_metas() e include_metas() dentro de la sección <head>.

EL TÍTULO DE LA PÁGINA

indexSuccess:
metas:
title: Los tres cerditos

$this->getResponse()->setTitle(sprintf(‘Los %d cerditos’, $numero));

El título de la página se puede incluir en el layout a través del método include_metas(), a través de include_title() o ambos, ya que es totalmente válido tener una etiqueta <meta name=»title»> o una etiqueta <title>.

INCLUIR ARCHIVOS

indexSuccess:
stylesheets: [miestilo1, miestilo2]
javascripts: [miscript]

$this->getResponse()->addStylesheet(‘miestilo1’);
$this->getResponse()->addStylesheet(‘miestilo2’);
$this->getResponse()->addJavascript(‘miscript’);

La extensión de los archivos no es necesario ponerla, a no ser que tengan una extensión diferente a la habitual (.css para archivos de estilos, .js para archivos javascript).

La inclusión de los archivos en la cabecera de la página es automática, no se necesita ningún método para añadirlos.

Recuerda que se sigue aplicando la configuración en cascada, por tanto los archivos que añadas a view.yml de la aplicación se mostrarán en todas las páginas de la aplicación.

view.yml de la aplicación:

default:
stylesheets: [principal]

view.yml del módulo:

indexSuccess:
stylesheets: [especial]

all:
stylesheets: [otra]

Si no se quiere incluir un archivo definido en alguno de los niveles de configuración superiores, se puede añadir un signo – delante del nombre del archivo en la configuración de más bajo nivel.

Ejemplo de archivo view.yml en el módulo y que evita incluir algunos de los archivos incluidos desde el nivel de configuración de la aplicación:

indexSuccess:
stylesheets: [-principal, especial]

all:
stylesheets: [otra]

Para eliminar todas las hojas de estilos o todos los archivos de JavaScript, se puede utilizar la siguiente sintaxis:

indexSuccess:
stylesheets: [-*]
javascripts: [-*]

Se puede ser todavía más preciso al incluir los archivos, ya que se puede utilizar un parámetro adicional para indicar la posición en la que se debe incluir el archivo (sólo se puede indicar la posición primera o la última):

# En el archivo view.yml
indexSuccess:
stylesheets: [especial: { position: first }]

// En la acción
$this->getResponse()->addStylesheet(‘especial’, ‘first’);

Para modificar el atributo media de la hoja de estilos incluida, se pueden modificar las opciones por defecto de Symfony:

indexSuccess:
stylesheets: [principal, impresora: { media: print }]

$this->getResponse()->addStylesheet(‘impresora’, », array(‘media’ => ‘print’));

Html devuelto por Symfony:

$this->getResponse()->addStylesheet(‘impresora’, », array(‘media’ => ‘print’));

CONFIGURACIÓN DEL LAYOUT

Normalmente Symfony, por defecto, utilizará la plantilla guardada en la carpeta /templates de la aplicación llamada layout.php, pero podemos indicarle cualquier otro layout:

indexSuccess:
layout: mi_layout

$this->setLayout(‘mi_layout’);

Si no se necesita ningún layout, se puede eliminar:

indexSuccess:
has_layout: false

$this->setLayout(false);

Symfony: Archivos de configuración

0

Bueno, sigo dandole caña a Symfony a través del manual en español, y después de practicar un poco con los conocimientos que he adquirido últimamente, puedo haceros un resumen de lo que os vais a encontrar.

(más…)

Pasar un proyecto symfony de un servidor a otro (a capón xD)

6

Sí, soy un poco bestia para algunas cosas jejeje; en este caso tuve que pasar el proyecto con el que estaba trabajando en el portatil al ordenador de sobremesa. En el portatil tengo instalada una versión de WAMP y en el sobremesa AppServ así que cuando pasé la carpeta del proyecto con un copy&paste y fui a ejecutarlo al navegador, obviamente no funcionaba, exactamente daba este error:

Warning: sfAutoload::require(C:/wamp/www/sf_sandbox/lib/vendor/symfony/lib/plugins/sfDoctrinePlugin/lib/database/sfDoctrineDatabase.class.php) [sfautoload.require]: failed to open stream: No such file or directory in F:\AppServ\www\sf_sandbox\lib\vendor\symfony\lib\autoload\sfAutoload.class.php on line 188

Fatal error: sfAutoload::require() [function.require]: Failed opening required ‘C:/wamp/www/sf_sandbox/lib/vendor/symfony/lib/plugins/sfDoctrinePlugin/lib/database/sfDoctrineDatabase.class.php’ (include_path=’.;F:\AppServ\php5\pear’) in F:\AppServ\www\sf_sandbox\lib\vendor\symfony\lib\autoload\sfAutoload.class.php on line 188

(más…)

Ir arriba