registerbundles not generate framework create php bundle symfony

php - not - ¿Qué debería representar un paquete en Symfony2?



symfony framework bundle (3)

Esto podría ser una cosa obvia para usted, pero, incluso después de leer muchos manuales y blogs, aún no estoy seguro de qué debería representar un paquete en Symfony2 en una página web. Y es difícil adivinarlo desde las aplicaciones de demostración simples.

Por ejemplo: tengo un sitio que está dividido en dos partes (una es solo un dominio de segundo nivel como example.com y otra es dom2.example.com ). Cada una de estas dos partes tiene algunas secciones propias, a veces iguales (como noticias) a veces diferentes.

¿Cuál sería la representación correcta de esto en symfony2? Debería tener

  • un MySite/site1 y MySite/site2 y hacer las diferentes secciones a través de diferentes controladores, o
  • paquetes Site1/News y Site2/News , o
  • paquetes MySite/Site1News y MySite/Site2News etc.

... o me estoy equivocando en esto?

La forma en que entiendo un paquete es que es similar a lo que los CMS como, por ejemplo, Typo3 o Drupal llaman un "complemento". Por lo tanto, debe ser idealmente autónomo y estar escrito de forma que también pueda usarse en otros proyectos.

Por ejemplo, en su caso crearía un "staticHtmlBundle" que contiene todas las páginas estáticas de su sitio web, divididas dentro de site.com y dom2.site.com.

Luego crearía un "paquete de noticias" que contiene todas las noticias-artículos, tal vez incluso basado en bases de datos con una pequeña sección de administración donde puedes editarlos y asignarlos a diferentes canales (en tu caso es site.com, dom2. sitio.com). Una página estática dentro de staticHtmlBundle llamaría a newsBundle y mostraría sus datos (como, por ejemplo, una lista de noticias o una vista detallada, etc.).

Si mantiene todo lo más abstracto y reutilizable posible, ¡incluso podría publicar el newsBunde en el repositorio Symfony 2 Bundle y compartirlo con la comunidad!

La forma en que percibo los paquetes Symfony2 es que proporcionan un sistema modular que le permite no solo ampliar y anular el código php, sino también cualquier recurso que puedan o no incluir.

Una vez dicho esto, considere que tiene una API y desea transferir un objeto.
¿Cómo lo harías tú?

Por supuesto, puedes hacerlo manualmente, pero ¿no sería bueno que Symfony lo haga por ti?

Mi forma de hacerlo incluiría 3 paquetes, JMSSerializerBundle y FosRestBundle .

  1. Un paquete para el lado del cliente - MyCompany/ClientBundle
  2. Un paquete para el lado del servidor - MyCompany/ServerBundle
  3. Un paquete que contiene todos los objetos de transferencia de datos que me gustaría poder transferir: MyCompany/CommonBundle .

Dentro de MyCompany/CommonBundle tendría las clases que usaría para mis objetos de transferencia de datos junto con las reglas de serialización con las que tendría que proporcionar el JMSSerializerBundle . Pueden estar en forma de anotaciones xml, yml o php.

Una vez que tenga un objeto lleno con los datos, puede usar return y FosRestBundle lo serializará por usted. La serialización dependerá del enrutamiento, por lo que puede tener el objeto serializado en XML para un sistema y en JSON para otro. El punto clave es que tiene diferentes formatos de serialización y versiones que puede utilizar en un momento posterior.

En el lado del cliente, puede usar el convertidor de parámetros simple para convertir el JSON o XML recibido a un objeto directamente en el controlador sin complicaciones adicionales. También puede escribir algunas reglas de validación para que pueda verificar si el objeto está poblado como espera que sea.

En mi ejemplo, MyCompany/CommonBundle tiene objetos que serían utilizados por múltiples aplicaciones y serían idénticos. Tenerlo como un paquete separado lo ayuda a evitar la duplicación de código y hace que el mantenimiento a largo plazo sea mucho más fácil.

Espero haber logrado explicar esto. ¿Alguna pregunta?
Preguntar en los comentarios. Actualizará la respuesta en consecuencia.

También soy nuevo en Symfony y seguiré los resultados de esta pregunta con interés, pero por lo que vale, mi opinión es:

Un paquete es solo eso: un grupo de archivos, activos, clases y métodos PHP, pruebas, etc. La lógica de la agrupación puede ser lo que quieras. En algunos casos, es realmente obvio qué es la agrupación y por qué se ha realizado; por ejemplo, si escribiera un sistema de blog para Symfony2 y quisiera lanzarlo, lo convertiría en un paquete. Ese es el tipo de ejemplo que se usa más en la documentación.

Pero también usaría paquetes para todo lo que quisiera lanzar como una pequeña característica. Digamos, por ejemplo, este paquete que crea rutas predeterminadas para todos sus controladores. No es un complemento / función completamente desarrollada como un blog o foro, pero es un código que puedo importar fácilmente a mi proyecto, se mantiene totalmente separado de todo lo demás, es un paquete.

Finalmente, también usaría paquetes internamente para su proyecto, de cualquier manera que tenga sentido para usted.

Mi opinión sobre tu situación específica:

Rapido y Facil:

  • MySite/MyCode - hace el trabajo, y tal vez no tenga una forma lógica de dividir el código que va a escribir.

Si hay algunas características más únicas entre los dos sitios y desea separarlos para mayor claridad:

  • MySite/SharedFeatures
  • MySite/Site1Features
  • MySite/Site2Features

Si realmente te gusta todo en su lugar, o si tienes un proyecto complejo, tal vez:

  • MySite/MySiteMain (funciones compartidas y miscelánea catch-all que no merece su propio paquete)
  • MySite/News
  • MySite/Site1FeatureSomethingOrOther
  • MySite/Site2FeatureSomethingOrOther

Definitivamente creo que desea atenerse a los grupos lógicos de código , por lo que creo que su ejemplo "paquetes Site1 / News y Site2 / News" y "MySite / Site1News y MySite / Site2News" no sería la mejor manera de hacerlo. Site1 y Site2 son implementaciones, por lo que hacer un paquete separado para la página de noticias de cada sitio parece ser contraproducente para mí; querría crear un componente de noticias y compilarlo para usarlo de dos formas diferentes.

En cuanto a su pregunta de dos dominios, puede apuntar ambos dominios al mismo código y probar dentro de su código para qué dominio se solicita, o puede verificar dos copias del mismo código y cambiar los archivos de configuración ligeramente ( no viola necesariamente la idea de DRY porque todavía edita el código en un lugar, y luego actualiza ambas copias).