El problema de echo es que aparece por pantalla de la web y no queremos que eso ocurra en producción.
El problema del sfLogger es que se accede a través del contexto y no lo tenemos en las tareas de línea de comandos (task in CLI) de Symfony.
Entonces, ¿Cómo escribir un mensaje de log desde el modelo que funcione en ambas situaciones?
ProjectConfiguration::getActive()
->getEventDispatcher()
->notify(new sfEvent(NULL, 'application.log', array('message' => "Mi mensaje",
'priority' => sfLogger::INFO)));
Os voy a soltar el código así sin anestesia ni nada.
implode (', ', array_intersect_key($_languages_, array_combine ( $object->getLanguagesArray(), $object->getLanguagesArray())));
Y ahora os explico qué hace. Básicamente tenemos un array no asociativo obtenido con $object->getLanguagesArray() que contiene una lista de claves de lenguajes (es, fr, en, por ejemplo). Y por otro lado tenemos un array asociativo con los nombres de todos los lenguajes como valor y sus códigos como clave. Algo como esto:
Array ( [0] => en [1] => pt [2] => fr [3] => es )
Array ( [aa] => Afar [ab] => Abjasio [af] => Afrikaans [am] => Amárico ...)
Y todo lo que quiero es una cadena, separada por comas con los nombres de los idiomas de $object.
Bueno, pues me ha costado casi una hora buceando en las funciones de array de PHP. Espero que a alguien por ahí le ahorre tiempo.
A menudo necesitas invocar el helper de tradicción, __(), desde fuera de la vista. Se puede hacer de dos maneras:
a) Cargarlo explícitamente y llamarlo igual que desde la vista (aunque se cargará dos veces, pues se seguirá cargando en la vista).
sfLoader::LoadHelpers(array('I18N'));
b) O utilizar una llamada puntual:
sfContext::getInstance()->getI18n()->__($text, $args, 'messages');
Traducción libre de: http://snippets.symfony-project.org/snippet/65
A menudo se declara en el esquema un campo como string (texto) cuando en la práctica va a ser una clave de un conjunto de valores. ¿Por qué no lo ponemos en el esquema como ‘type: Enum’? Por ejemplo porque no sabemos, en principio, cuales son los valores que se van a guardar ahí.
En ese caso el filtro no pondrá un desplegable con los valores, lógicamente, sino un input[type=text].
Si posteriormente queremos que en el filtro aparezcan los valores en forma de desplegable hacemos algo como esto:
$choices = array_merge(array('' => ''), <array_con_valores>);
$this->widgetSchema['myField'] = new sfWidgetFormSelect(array('choices' => $choices, 'multiple' => false));
Pues bien, esto mostrará el filtro tal y como lo queremos, pero no funcionará. ¿Qué falta? Pues que le digamos al filtro que tiene que filtrar por un conjunto de claves:
public function getFields() {
return array('myField' => 'Enum') + parent::getFields();
}
Es importante el orden, porque al existir ya ‘myField’ en el esquema, si hacemos la unión de los arrays al revés el valor recibido en el padre pisará el nuestro.
Estoy viendo y leyendo mucho últimamente, que en lugar de incluir las bibliotecas de jQuery y jQueryUI (y esto es aplicable al resto de bibliotecas disponibles) en tu propio servidor, es mejor alternativa utilizar los repositorios similares a los ofrecidos por Google (o el de Google).
<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.4.8/jquery.min.js"></script>¿Que por qué? Pues he recopilado tres ventajas y un inconveniente.
Las ventajas son:
Desventajas:
* Cuando encuentre tiempo escribiré sobre cómo solucionar este «problema»
UPDATE: La URL ha cambiado a (y no solo por el número de versión) https://ajax.googleapis.com/ajax/libs/jquery/1.5.1/jquery.min.js. Lo cual me hace pensar que esos cambios en la URL son nuevos problemas, y gordos.
Habitualmente los proyectos de symfony filtran la vista de manera que se evite la ejecución de código malicioso. Para ellos se sirve de los llamados Output Escaping Decorators. Sin embargo, en muchas ocasiones nos interesa (con cuidado) saltarnos este control.
Normalmente basta con hacer
$object->getAtributo(ESC_RAW) ó $object->getRawValue()->getAttributo()
Pero a veces no es un objeto lo que queremos utilizar. Pongamos que sea una cadena. En ese caso, la manera de actuar es la siguiente
$sf_data->getRaw('variable');
Si queremos ir más allá (mucho cuidado al hacer esto). Podemos desactivarlo para toda una acción desde el controlador:
public function executeMiAccion(sfWebRequest $request)
{
sfConfig::set('sf_escaping_strategy', false);
[...]
}
Últimamente he vuelto a dedicar algo de tiempo a la fotografía. No mucho la verdad, pero algo.
Y entre las cosas a las que dedico tiempo es a lo que yo he llamado «revelar mis fotos». ¿Revelar las fotos digitales? Sí, lo llamo revelar pero no es pasarlas a papel, es simplemente revisarlas con más o menos dedicación desde el formato RAW en el que las tomo y retocar un encuadre aquí, el contraste allá, el color en este otro sitio.
Cada foto me puede llevar entre dos-tres minutos y veinte minutos, dependiendo del tiempo que tenga, de la cantidad de fotos que vaya a crear.
Y todo este trabajo para que después cada uno lo vea como quiera en su navegador. ¿Que de qué hablo? De esto: http://www.xatakafoto.com/trucos-y-consejos/perfiles-de-color-e-internet De como los navegadores más «cool» ignoran mis indicaciones. Señores, a utilizar Firefox o Safari 4
En contra de lo que pensaba.
O al menos eso es lo que dice la RAE, que es la que manda en esto:
http://buscon.rae.es/draeI/SrvltGUIBusUsual?TIPO_HTML=2&TIPO_BUS=3&LEMA=embeber
Es tal la maraña de diferencias de renderizado de los diferentes navegadores que es habitual incluir, entre las hojas de estilo (CSS) de las diferentes páginas web una destinada a tratar de uniformizar ese renderizado antes de comenzar a construir una imagen para la web.
Pero un ejemplo del caos que puede llegar a ser eso está en esta página que nos muestra 11, sí lector@s, ONCE, maneras diferentes de construir esa hoja de estilos.
http://perishablepress.com/press/2007/10/23/a-killer-collection-of-global-css-reset-styles/
Por cierto, gracias, al menos puedo probar varias opciones cuando tengo que iniciar un proyecto nuevo.
Normalmente cuando quieres desinstalar un plugin de symfony basta con hacer:
$ symfony plugin:uninstall <nombre_plugin>
Pero a veces el resultado no es el deseado, obteniendo un error como este:
>> plugin uninstalling plugin "nombre_plugin" >> sfSymfonyPluginManager Plugin "nombre_plugin" is not installed
Intenta en ese caso
symfony plugin:uninstall symfony/nombre_plugin
P.D: Lo que no te evitas en ningún caso es la eliminación manual del enlace simbólico en ./web que se crea al instalar el plugin con el publish-assets
Comentarios recientes