20.1.1. Los plugins de Symfony
Un plugin de Symfony es una forma de agrupar y distribuir un subconjunto de archivos de tu proyecto. Al igual que los proyectos, los plugins pueden contener clases, helpers, archivos de configuración, tareas, esquemas de datos e incluso archivos web como CSS y JavaScript.
20.1.2. Plugins privados
El uso más habitual de los plugins es la posibilidad de compartir código entre tus diferentes aplicaciones o incluso entre diferentes proyectos. Recuerda que las aplicaciones Symfony sólo comparten el modelo. Gracias a los plugins, las aplicaciones pueden compartir muchos otros componentes.
Si quieres reutilizar un mismo esquema de datos en diferentes proyectos o incluso un módulo entero, crea un plugin que contenga esos archivos. Como un plugin simplemente es un directorio, puedes moverlo fácilmente de un sitio a otro creando un repositorio de Subversion y empleando la propiedad svn:externals o simplemente copiando y pegando los archivos de un proyecto a otro.
Denominamos a estos plugins "privados" porque su uso se restringe a un programador o una empresa concreta, ya que no están disponibles de forma pública.
Nota También puedes crear paquetes para tus plugins privados y después crear tu propio canal de plugins Symfony para poder instalarlos mediante la tarea plugin:install.
20.1.3. Plugins públicos
Los plugins públicos son aquellos que están disponibles para que cualquier usuario de la comunidad de Symfony los pueda descargar e instalar en sus proyectos. A lo largo de este tutorial ya hemos utilizado un par de plugins públicos: sfGuardPlugin y sfFormExtraPlugin.
Aunque técnicamente son iguales que los plugins privados, la diferencia reside en que cualquiera puede instalarlos y utilizarlos en sus proyectos. Más adelante explicaremos cómo publicar un plugin público en el sitio web de Symfony.
20.1.4. Otra forma de organizar el código
Existe otra forma de utilizar los plugins muy diferente a la reutilización de código. Los plugins permiten organizar el código del proyecto de forma completamente distinta. En vez de organizar los archivos por capas (las clases del modelo en el directorio lib/model/, las plantillas en el directorio templates/, etc.) puedes organizar los archivos según su funcionalidad: guardar juntos todos los archivos relacionados con las ofertas de trabajo (modelos, módulos y plantillas), guardar juntos todos los archivos relacionados con el CMS, etc.