07 Jul 10 Logs manuales y personalizados en Symfony
Suele ser una buena práctica tener un archivo de logs con las últimas acciones más importantes que se han hecho en nuestro sitio web: nuevo usuario registrado, se ha escrito un nuevo comentario, se ha editado o borrado un artículo, etc.
Symfony tiene un sistema de logs bastante decente, que nos informa de todo lo que ocurre cada vez que cargamos una nueva página. Vamos a hacer algo sencillo: vamos a escribir nuestros propios mensajes de log personalizados y los escribiremos manualmente en el momento que consideremos oportuno y deseamos tener un control. Además, escribiremos estos logs en un archivo aparte del que utiliza Symfony por defecto. Así podremos leer directamente ese archivo sin tener otros logs mezclados con los que realmente nos interesa.
Primero, vamos a crear un nuevo archivo llamado CustomLog.class.php en la carpeta /lib/:
1 2 3 4 5 6 7 8 9 10 11 | <?php class CustomLog{ static public function newLog($message) { $logFile = sfConfig::get('sf_log_dir').'/custom_logs.log'; $custom_log = new sfFileLogger(new sfEventDispatcher(), array('file' => $logFile)); $custom_log->info($message); } } |
El archivo donde guardaremos nuestros logs personalizados, lo encontraremos en “/log/custom_logs.log”.
Para escribir un nuevo log desde cualquier parte del código, simplemente deberemos hacer:
1 | CustomLog::newLog("Escribimos un nuevo log"); |
Si abrimos nuestro archivo de logs personalizados, encontraremos algo como esto:
1 | Jul 05 22:31:41 symfony [info] Escribimos un nuevo log |
Así podremos llevar un control de lo que ocurre en nuestra web.
Quizás haya una forma mejor de hacerlo. Si es así, no dudes en dejar tu propuesta en los comentarios. A lo mejor también sería conveniente escribir esas 3 lineas dentro de un try.. catch, por lo que pudiera pasar.
19 Jun 10 Symfony: Migrar de Propel a Doctrine
Desde que empecé con Symfony siempre he preferido utilizar Propel como ORM de mis proyectos. Me sentía cómodo utilizándolo excepto en esas ocasiones en las que se complicaba demasiado la consulta y había que tirar de ‘criteriones’ (al final optaba por construir la sql a mano). Había leído sobre Doctrine pero nunca me había parado a probarlo y utilizarlo ya que, como digo, me sentía muy cómodo con Propel y ni siquiera me planteaba cambiar.
En la nueva empresa donde trabajo (BlackSlot) he empezado a utilizar Doctrine y, ante mi sorpresa, me ha encantado. Me he dado cuenta de que si sabes sql es muy fácil aprender Doctrine y con resultados muy buenos. Con Propel, aunque sepas sql, tienes que aprender a usarlo y pensar las conversiones desde sql a Propel. Es un lenguaje nuevo.
Ante este escenario y como tengo un proyecto recién empezado, me decidí a migrarlo de Propel a Doctrine.
Tengo que destacar que la migración es realmente costosa. Si no fuese por que acabo de empezar el proyecto y no está muy avanzado, hubiese tenido que seguir con Propel. Personalmente, lo que más cuesta es transformar todo el modelo a Doctrine (todo depende de cuanto lleves hecho). Si es un proyecto acabado y bastante elaborado, te puede llevar días. Al modelo hay que añadir el modificar el schema.yml con el formato apropiado para Doctrine.
Otro quebradero de cabeza son los plugins en Propel que has utilizado en tu proyecto. El más típico es el sfGuardPlugin para llevar las cuentas de usuario. Tendrás que instalar el plugin sfDoctrineGuardPlugin que es el equivalente para Doctrine.
Si aún después de haber leído esto, sigues queriendo migrar de Propel a Doctrine un proyecto empezado, estos son los pasos que tienes que seguir:
(more…)
