Elementos declarados obsoletos en Symfony 1.3

Este tutorial detalla todas las opciones de configuración, clases, métodos, funciones y tareas que se han eliminado y/o declarado obsoletas en Symfony 1.3.

Plugins internos

Los siguientes plugins internos se han declarado obsoletos en Symfony 1.3 y se han eliminado en Symfony 1.4:

  • sfCompat10Plugin: haber declarado como obsoleto este plugin supone que ahora también son obsoletos todos los elementos del framework que dependen de este plugin (el generador de la parte de administración de Symfony 1.0 y el sistema de formularios de Symfony 1.0). También se ha declarado obsoleto el tema del generador de la parte de administración de Symfony 1.0 que se encuentra en lib/plugins/sfPropelPlugin/data/generator/sfPropelAdmin.
  • sfProtoculousPlugin: los helpers de este plugin generan código intrusivo, por lo que ya no se deberían utilizar (existen plugins externos para generar código no intrusivo).

Métodos y funciones

Los siguientes métodos y funciones se han declarado obsoletos en Symfony 1.3 y han sido eliminados en Symfony 1.4:

  • sfToolkit::getTmpDir(): puedes reemplazarlo por el método sys_get_temp_dir()
  • sfToolkit::removeArrayValueForPath(), sfToolkit::hasArrayValueForPath() y getArrayValueForPathByRef()
  • sfValidatorBase::setInvalidMessage(): puedes sustituirlo por el nuevo método sfValidatorBase::setDefaultMessage()
  • sfValidatorBase::setRequiredMessage(): puedes reemplazarlo por el método sfValidatorBase::setDefaultMessage()
  • sfTesterResponse::contains(): puedes emplear el nuevo método matches(), que además es mucho más potente
  • Los métodos isRedirected(), isStatusCode(), responseContains(), isRequestParameter(), isResponseHeader(), isUserCulture(), isRequestFormat() y checkResponseElement() de sfTestFunctionalBase: estos métodos eran obsoletos desde Symfony 1.2 y se han sustituido por las nuevas clases de tipo tester.
  • Los métodos isCached() y isUriCached() de sfTestFunctional: estos métodos eran obsoletos desde Symfony 1.2 y se han sustituido por las nuevas clases de tipo tester.
  • sfFilesystem::sh(): puedes reemplazarlo por el nuevo método sfFilesystem::execute(). Debes tener en cuenta que el valor devuelto por este método es un array compuesto por la salida de stdout y la salida de stderr.
  • sfAction::getDefaultView(), sfAction::handleError() y sfAction::validate(): estos métodos se declararon obsoletos en Symfony 1.1, ya que no eran muy útiles. Para funcionar necesitan que la opción compat_10 esté establecida a on.
  • sfComponent::debugMessage(): se puede sustituir por el helper log_message().
  • sfApplicationConfiguration::loadPluginConfig(): utiliza initializePlugins() en su lugar.
  • sfLoader::getHelperDirs() y sfLoader::loadHelpers(): puedes utilizar los métodos del objeto sfApplicationConfiguration que tienen el mismo nombre. Como todos los métodos de la clase sfLoader se han declarado obsoletos, la clase sfLoader se ha eliminado en Symfony 1.4.
  • sfController::sendEmail(): utiliza el nuevo mailer de Symfony 1.3.
  • sfGeneratorManager::initialize(): es un método que no hace nada.
  • debug_message(): utiliza en su lugar el helper log_message().
  • sfWebRequest::getMethodName(): se puede sustituir por el método getMethod().
  • sfDomCssSelector::getTexts(): utiliza matchAll()->getValues().
  • sfDomCssSelector::getElements(): utiliza matchAll().
  • sfVarLogger::getXDebugStack(): sustitúyelo por sfVarLogger::getDebugBacktrace().
  • sfVarLogger: el valor debug_stack se sustituye por el valor debug_backtrace.
  • sfContext::retrieveObjects(): este método sólo se utiliza en ObjectHelper, que ha sido declarado obsoleto.

Los siguientes métodos y funciones se han eliminado en Symfony 1.3:

  • sfApplicationConfiguration::checkSymfonyVersion(): más adelante se explica con la opción de configuración check_symfony_version

Clases

Las siguientes clases se han declarado obsoletas en Symfony 1.3 y han sido eliminadas en Symfony 1.4:

  • sfDoctrineLogger: sustitúyela por sfDoctrineConnectionProfiler.
  • sfNoRouting and sfPathInfoRouting
  • sfRichTextEditor, sfRichTextEditorFCK y sfRichTextEditorTinyMCE: se han reemplazado por el sistema de widgets (ver la sección Helpers más adelante)
  • sfCrudGenerator, sfAdminGenerator, sfPropelCrudGenerator y sfPropelAdminGenerator: estas clases las utilizaba el generado de administraciones de Symfony 1.0.
  • sfPropelUniqueValidator, sfDoctrineUniqueValidator: se utilizaban en el sistema de formularios de Symfony 1.0.
  • sfLoader: su eliminación se explica en la sección anterior.
  • sfConsoleRequest, sfConsoleResponse, sfConsoleController
  • sfDoctrineDataRetriever, sfPropelDataRetriever: estas clases sólo las utiliza ObjectHelper, que ha sido declarado como obsoleto
  • sfWidgetFormI18nSelectLanguage, sfWidgetFormI18nSelectCurrency y sfWidgetFormI18nSelectCountry: utiliza los widgets correspondientes de tipo Choice (sfWidgetFormI18nChoiceLanguage, sfWidgetFormI18nChoiceCurrency y sfWidgetFormI18nChoiceCountry respectivamente) ya que su comportamiento es idéntico y tienen más opciones de configuración.
  • sfWidgetFormChoiceMany, sfWidgetFormPropelChoiceMany, sfWidgetFormDoctrineChoiceMany, sfValidatorChoiceMany, sfValidatorPropelChoiceMany y sfValidatorPropelDoctrineMany: puedes utilizar las clases con el mismo nombre pero sin el sufijo Many y estableciendo la opción multiple a true
  • SfExtensionObjectBuilder, SfExtensionPeerBuilder, SfMultiExtendObjectBuilder, SfNestedSetBuilder, SfNestedSetPeerBuilder, SfObjectBuilder y SfPeerBuilder: estas clases constructoras propias de Propel se han sustituido por los nuevos comportamientos de Propel 1.4.

Las siguientes clases se han declarado obsoletas en Symfony 1.3:

  • sfCommonFilter: el tutorial de actualización a Symfony 1.3/1.4 explica con detalle por qué se ha eliminado este filtro y cómo se puede actualizar el código.

Helpers

Los siguientes grupos de helpers se han declarado obsoletos en Symfony 1.3 y se han eliminado en Symfony 1.4:

  • Todos los helpers relacionados con el sistema de formularios de Symfony 1.0 y proporcionados por el plugin sfCompat10Plugin: DateForm, Form, ObjectAdmin, Object y Validation.

El helper form_tag() del grupo Form se ha trasladado al grupo Url, por lo que todavía se puede utilizar en Symfony 1.4.

La carga de helpers desde el include path de PHP se ha declarado obsoleta en Symfony 1.3 y se ha eliminado en Symfony 1.4. Los helpers deben encontrarse obligatoriamente en el directorio lib/helper/ del proyecto, de una aplicación o de un módulo.

Opciones de configuración

Las siguientes opciones del archivo de configuración settings.yml se han eliminado en Symfony 1.3:

  • check_symfony_version: esta opción se añadió hace muchos años para permitir el borrado automático de la cache cuando se cambiaba la versión de Symfony. Se trataba de una opción útil en los servicios de hosting compartidos donde la misma versión de Symfony se comparte entre todos los clientes. Como esta práctica está desaconsejada desde Symfony 1.1 (es mejor incluir las librerías de Symfony en cada proyecto) esta opción ya no tiene sentido. Además, si la opción está activada, esta comprobación añade una pequeña penalización en el rendimiento de cada petición.
  • max_forwards: esta opción establece el número máximo de redirecciones permitidas en una petición antes de que Symfony lance una excepción. Además de eliminar esta opción, se ha establecido en 5 el máximo número de redirecciones, ya que si este número no es suficiente, tu aplicación está mal diseñada y su rendimiento debe ser lamentable.
  • sf_lazy_cache_key: esta opción se introdujo en Symfony 1.2.6 como una posible gran mejora en el rendimiento de las aplicaciones, ya que permite activar en la cache de la vista la generación tardía de las claves de cache. Aunque creemos que se trata de una buena idea, algunos usuarios confían en que se invoque sfViewCacheManager::isCacheable() incluso cuando la propia acción no se puede guardar en la cache. Desde Symfony 1.3 el comportamiento es igual que si la opción sf_lazy_cache_key estuviera configurada a true.
  • strip_comments: esta opción permite deshabilitar el borrado de los comentarios, ya que el tokenizer de las versiones 5.0.X de PHP contenía muchos errores. No obstante, como Symfony 1.3 sólo funciona con PHP 5.2 o superior y como se han solucionado otros errores asociados al borrado de comentarios, esta opción tampoco tiene sentido.
  • lazy_routes_deserialize: ya no se necesita esta opción.

Las siguientes opciones de configuración se han declarado obsoletas en Symfony 1.3 y se han eliminado en Symfony 1.4:

  • calendar_web_dir, rich_text_js_dir: estas opciones las utiliza el grupo de helpers Form, que ha sido declarado obsoleto en Symfony 1.3.
  • validation_error_prefix, validation_error_suffix, validation_error_class y validation_error_id_prefix: estas opciones las utiliza el grupo de helpers Validation, que ha sido declarado obsoleto en Symfony 1.3.
  • is_internal (en module.yml): esta opción se utilizaba para impedir que las acciones pudieran invocarse desde el navegador. Se empleaba para proteger el envío de emails en Symfony 1.0. Como el sistema de envío de emails ya no necesita este truco, esta opción ya no tiene sentido.

Tareas

Las siguientes tareas se han eliminado en Symfony 1.3:

  • project:freeze y project:unfreeze: estas tareas se empleaban para incluir las librerías de Symfony dentro del propio proyecto. Ya no son necesarias porque se recomienda incluir siempre las librerías de Symfony dentro del proyecto. Además, cambiar de una versión de Symfony a otra ahora es muy sencillo, ya que solamente debes cambiar una ruta dentro de la clase ProjectConfiguration. Incluir Symfony a mano también es muy sencillo, porque solamente debes copiar el directorio de Symfony en algún directorio del proyecto (te recomendamos que lo copies en lib/vendor/symfony/).

Las siguientes tareas se han declarado obsoletas en Symfony 1.3 y se han eliminado en Symfony 1.4:

  • Todos los alias de todas las tareas de Symfony 1.0.
  • propel:init-admin: se utilizaba para generar los módulos de administración de Symfony 1.0.

Las siguientes tareas de Doctrine se han fusionado en la nueva tarea doctrine:build y han sido eliminadas en Symfony 1.4:

  • doctrine:build-all
  • doctrine:build-all-load
  • doctrine:build-all-reload
  • doctrine:build-all-reload-test-all
  • doctrine:rebuild-db
  • doctrine:reload-data

Otros elementos

Los siguientes comportamientos se han declarado obsoletos en Symfony 1.3 y han sido eliminados en Symfony 1.4:

  • El soporte de la notación tipo array ([]) en los métodos sfParameterHolder::get(), sfParameterHolder::has(), sfParameterHolder::remove(), sfNamespacedParameterHolder::get(), sfNamespacedParameterHolder::has() y sfNamespacedParameterHolder::remove() se ha declarado obsoleta y se ha eliminado en Symfony 1.4 (lo que mejora el rendimiento).

La línea de comandos de Symfony ya no acepta la opción global --dry-run porque no la utilizaba ninguna de las tareas propias de Symfony. Si alguna de tus taras hace uso de esta opción, la puedes añadir como opción local de la clase de tu tarea.

Las plantillas de Propel para el generador de administraciones de Symfony 1.0 y el CRUD de Symfony 1.0 se han eliminado en Symfony 1.4 (plugins/sfPropelPlugin/data/generator/sfPropelAdmin/).

El calendario “Dynarch calendar” (que se encontraba en data/web/calendar/) se ha eliminado en Symfony 1.4 porque sólo lo utiliza el grupo de helpers Form, que también se ha eliminado en Symfony 1.4.

A partir de Symfony 1.3, la página que indica que la aplicación no está disponible sólo se busca en los directorios %SF_APP_CONFIG_DIR%/ y %SF_CONFIG_DIR%/. Si aún guardas esta página en el directorio %SF_WEB_DIR%/errors/, debes cambiarla de sitio antes de actualizar a Symfony 1.4.

Ya no se genera el directorio doc/ dentro de la raíz del proyecto, ya que Symfony no lo utilizaba. La opción sf_doc_dir relacionada también ha sido eliminada.

La opción sfDoctrinePlugin_doctrine_lib_path, que antes se utilizaba para indicar un directorio lib/ propio para Doctrine se ha declarado obsoleta en Symfony 1.3 y se ha eliminado en Symfony 1.4. Puedes utilizar en su lugar la opción sf_doctrine_dir.

Todas las clases de tipo Base* generadas automáticamente ya no son de tipo abstract.