Interfaz de Línea de Comando

traducido por arhak

Introducción

Muchas de las tareas que un desarrollador ejecuta durante la construcción y mantenimiento de una aplicación web puede ser manejada por la Interfaz de Línea de Comando (CLI) de symfony. El Capítulo 16 describe algunas de estas tareas en detalle, mientras que este capítulo las lista todas con una breve descripción.

Núcleo (core) CLI

El script symfony es un script PHP que se encuentra en la raíz de un proyecto. El comando symfony espera un tarea (task), y algunas tareas requieren argumentos adicionales. Para invocarlo, utilice la siguiente sintaxis:

$ cd miproyecto
$ php symfony <NOMBRE_DE_TAREA> [argumentos]

Una tarea también puede tener opciones:

$ php symfony <NOMBRE_DE_TAREA> [argumentos] --opcion1=valor --opcion2

Nota: El CLI de symfony funciona solamente desde la raíz de un proyecto symfony

El sandbox de symfony (caja de arena de symfony) contiene ejecutables para Windows y plataformas *nix que deben permitir una invocación aún más rápida:

$ ./symfony <TAREA> [parámetros]      #  *nix
$ symfony <TAREA> [parámetros]        #  Windows

Los ejemplos de este capítulo utilizarán el ejecutable php, pero puede ser omitido si el proyecto tiene los ejecutables apropiados.

Para listar todas las posibles tareas, invocar:

$ php symfony

Para mostrar la versión instalada del paquete symfony, teclear:

$ php symfony -V

Unas pocas tareas tienen atajo (shortcut), más rápido de escribir, que tiene el mismo efecto.

$ php symfony cc

// hace los mismo que
$ php symfony cache:clear

Cuando una excepción ocurre, se puede desear obtener la traza de la pila (stack trace) y una explicación detallada. Adicione la opción -t antes del nombre de la tarea para obtener la traza.

Tareas CLI

Cada tarea integrada (built-in) tiene una descripción completa del objetivo de la tarea, todos los argumentos y todas las opciones que acepta. Para mostrar esta información, se puede utilizar la tarea help:

$ php symfony help cache:clear

Generación de estructura

$ php symfony generate:project <NOMBRE_DE_PROYECTO>

Inicializa un nuevo proyecto symfony.

$ php symfony generate:app <NOMBRE_DE_APLICACIÓN>

Inicializa una nueva aplicación symfony.

$ php symfony generate:module <NOMBRE_DE_APLICACIÓN> <NOMBRE_DE_MÓDULO>

Inicializa un nuevo módulo symfony.

Puede encontrar más acerca de estos comandos en el Capítulo 16.

Generación del modelo

$ php symfony configure:database mysql://localhost/nombre_de_base_de_datos

Configura la información de la base de datos para config/databases.yml y config/propel.ini.

$ php symfony propel:build-model

Genera las clases Propel para el modelo actual, basado en los ficheros schema (YAML or XML) del directorio config/.

Las configuraciones de conexión utilizadas por los siguientes comandos se toman de la configuración config/propel.ini.

$ php symfony propel:build-sql

Genera el código SQL para crear las tablas descritas en schema.yml, en un fichero data/schema.sql.

$ php symfony propel:build-db

Crea una base de datos vacía acorde con las configuraciones de conexión.

$ php symfony propel:insert-sql

Inserta el código SQL de data/schema.sql en la base de datos.

$ php symfony propel:build-forms

Genera los formularios asociados con el modelo.

$ php symfony propel:build-all

Ejecuta propel:build-model, propel:build-sql, propel:build-forms, y propel:insert-sql todo en un solo comando.

Puede encontrar más acerca de estos comandos en el Capítulo 8.

Manipulación de esquema (schema)

$ php symfony propel:build-schema [--xml]

Crea un schema.yml a partir de una base de datos existente. Si el parámetro --xml es añadido, las tareas crean un schema.xml en lugar de la versión YAML.

$ php symfony propel:schema-to-yml

Crea versiones YAML de los esquemas XML encontrados.

$ php symfony propel:schema-to-xml

Crea versiones XML de los esquemas YML encontrados.

Manipulación de datos

$ php symfony propel:data-load  <NOMBRE_DE_APLICACIÓN> [--env=<NOMBRE_DE_ENTORNO>] [--dir=<DIRECTORIO_O_FICHERO_DE_FIXTURES>]

Carga todos los datos del directorio data/fixtures/ a menos que se especifique otro. El entorno por defecto es dev. El directorio de fixtures debe ser especificado relativo al directorio de datos del proyecto, por ejemplo fixtures (por defecto) o datosprueba o especificar un solo fichero fixtures/fichero.yml.

$ php symfony propel:build-all-load  <NOMBRE_DE_APLICACIÓN>

Ejecuta propel:build-all luego propel:data-load. Acepta los mismos argumentos que propel:data-load.

$ php symfony propel:data-dump <NOMBRE_DE_APLICACIÓN> [<DESTINO>] [--env=<NOMBRE_DE_ENTORNO>]

Descarga los datos de la base de datos hacia un fichero en el directorio de fixtures en formato YAML.

Herramientas de desarrollo

$ php symfony cache:clear [--app=<NOMBRE_DE_APLICACIÓN>] [--type=template|config|i18n|routing] [--env=<NOMBRE_DE_ENTORNO>]

Limpia la información en caché (cached) (atajo: cc) (vea más en el Capítulo 12).

$ php symfony project:permissions

Corrige los permisos de los directorios, para cambiar a 777 los directorios que necesitan ser de escritura. Los permisos pueden estar rotos si se utiliza un checkout de un repositorio SVN.

$ php symfony project:freeze <DIRECTORIO_DATA_DE_SYMFONY>
$ php symfony project:unfreeze

Copia todas las librerías necesarias de symfony en los directorios data/, lib/ y web/sf/ del proyecto. Entonces el proyecto se convierte en una especie de sandbox, es decir, en una aplicación independiente (standalone) sin dependencias y lista para ser transferido a producción via FTP. Funciona bien con instalaciones PEAR al igual que con enlaces simbólicos (symbolic links). El proyecto se descongela con la tarea project:unfreeze.

$ php symfony project:deploy <NOMBRE_DE_CONFIGURACIÓN_DE_SERVIDOR> [--go]

Sincroniza el proyecto actual con otra máquina (vea más en el Capítulo 16).

Pruebas

$ php symfony test:unit <UNIDAD_DE_PRUEBA>

Lanza una prueba de unidad (unit test) ubicada en el directorio test/unit/. El parámetro puede ser el nombre de un solo fichero de prueba de unidad (omitiendo el sufijo Test.php), un grupo de ficheros de pruebas de unidad, o un camino de ficheros con comodines (wildcards). Si no se especifica el nombre de la prueba, todas las pruebas de unidad son ejecutadas.

$ php symfony test:unit

Lanza todas las pruebas de unidad en modo arnés (harness mode).

$ php symfony test:functional <NOMBRE_DE_APLICACIÓN> <PRUEBA>

Lanza una prueba funcional (functional test) para la aplicación especificada. El parámetro PRUEBA puede ser un solo fichero de prueba funcional (omitiendo el sufijo Test.php), un grupo de ficheros de pruebas funcionales, o un camino de ficheros con comodines.

$ php symfony test:functional <NOMBRE_DE_APLICACIÓN>

Lanza todas las pruebas funcionales de una aplicación en modo arnés.

$ php symfony test:all

Lanza todas las pruebas de unidad y funcionales en modo arnés.

Puede encontrar más acerca de las pruebas en el Capítulo 15.

Administración de proyecto

$ php symfony project:disable <NOMBRE_DE_APLICACIÓN> <NOMBRE_DE_ENTORNO>

Envía (forwards) al usuario al módulo y acción indisponible (unavailable) especificados en el fichero settings.yml y actúa de la misma forma que si se ubiese especificado el sitio como indisponible en el fichero settings.yml. La ventaja sobre la especificación de indisponible es qeu se puede deshabilitar una sola aplicación para un solo entorno, en lugar de todo el proyecto.

$ php symfony project:enable <NOMBRE_DE_APLICACIÓN> <NOMBRE_DE_ENTORNO>

Habilita la aplicación y limpia la caché.

$ php symfony log:clear

Vacía los ficheros logs en el directorio log en las aplicaciones y entornos donde el fichero logging.yml especifique purge: on (que es el valor por defecto).

$ php symfony log:rotate <NOMBRE_DE_APLICACIÓN> <NOMBRE_DE_ENTORNO>

Fuerza una rotación de un fichero log. Las opciones de rotación son el período --period (el número de días que un solo log puede durar) y la historia --history (el número de copias de seguridad de ficheros log a conservar).

Generación de andamiaje (scaffolding) y administración

$ php symfony propel:generate-crud <NOMBRE_DE_APLICACIÓN> <NOMBRE_DE_MÓDULO> <NOMBRE_DE_CLASE>

Genera un nuevo módulo CRUD de Propel basado en una clase del modelo. La versión normal copia el código del framework hacia un nuevo módulo; si se añade la opción --generate-in-cache, la tarea crea un módulo vacío que hereda del que hay en el framework. En este caso, el código generado es visible solo en la carpeta cache/ (las acciones y plantillas generadas heredan del framework).

$ php symfony propel:init-admin <NOMBRE_DE_APLICACIÓN> <NOMBRE_DE_MÓDULO> <NOMBRE_DE_CLASE>

Inicializa un nuevo módulo admin de Propel basado en una clase del modelo.

Puede encontrar más acerca de estos comandos en el Capítulo 14.

Manipulación de plugins

$ php symfony plugin:install [<NOMBRE_DE_CANAL>/]<NOMBRE_DE_PLUGIN>

Instala un nuevo plugin. Para instalar un nuevo plugin de la wiki de symfony, el nombre de canal implícino es symfony.

$ php symfony plugin:upgrade [<NOMBRE_DE_CANAL>/]<NOMBRE_DE_PLUGIN>

Actualiza (upgrades) un plugin.

$ php symfony plugin:upgrade-all

Actualiza todos los plugins previamente instalados localmente

$ php symfony plugin:uninstall [<NOMBRE_DE_CANAL>/]<NOMBRE_DE_PLUGIN>

Desinstala un plugin.

Puede encontrar más acerca de los plugins en el Capítulo 17.

Completamiento automático

La wiki de symfony contiene ficheros de configuraciones contribuídas por los usuarios (user-contributed) para permitir completamiento automático de los comandos de symfony. Encuentre la que mejor se ajuste a su CLI:

• completamiento Bash
• completamiento Zsh