Soy nuevo en symfony2. Empecé con algunos tutoriales y luego comencé a construir SYMBLOG. Lo he entendido y puedo agregar o cambiar la funcionalidad. Tengo un poco de confusión en el flujo de trabajo, me refiero a cómo funcionan los archivos para generar una página o producir un resultado. ¿Alguien puede explicarme en detalle desde el principio cómo funciona este flujo en Symfony2? a partir de la solicitud del usuario, digamos que el usuario ingresa una url hasta que symfony2 muestre los resultados. por favor incluye el routing.yml en el flujo. ?Flujo de trabajo con Symfony2?
Respuesta
Debería consultar este enlace. Symfony - the big picture
Explica en detalle todos los pasos involucrados desde el momento en que ingresa la URL en el navegador hasta la página que se muestra.
Básicamente todas las solicitudes van a un controlador frontal. Su trabajo es enrutar las solicitudes al código de controlador apropiado. Lo hace con la ayuda de las rutas definidas en el archivo app/config/routing.yml
. Los controladores que se definen en src/<BundleName>/Controller/<name>
realizan alguna lógica comercial, como obtener datos del Modelo (Repositorio) y enviar esa información a la Vista (Plantillas). Las vistas son simplemente código HTML. Symfony usa un motor de plantillas llamado Twig. En lugar de incluir los bloques <?php ... ?>
en el código HTML, Symfony pasa los datos del controlador y se puede usar fácilmente dentro de la vista dentro de los bloques Twig {% %}
o {{ }}
.
En pocas palabras, aquí es el flujo de trabajo:
- navegador envía Solicitud
- Solicitud recibida en el controlador frontal
web/app_dev.php
o web/app.php- controlador frontal comprueba las rutas definidas en
app/config/routing.yml
y envía la solicitud al controlador apropiado definido ensrc/<BundleName>/Controller/<controller_name>
- El controlador prepara el contenido que se necesita en el HT ML (Ejemplo - consultas a la base de datos desde
src/<BundleName>/Repository
) y envía la información a la vista -src/Resources/views/<twig file name>
- La vista crea el código HTML y lo envía de vuelta al controlador
- El controlador crea una respuesta HTTP y lo envía de vuelta al navegador
hay cosas como la aplicación/AppKernel que vienen en el medio pero he saltamos.
Aquí están los extractos útiles del enlace que aparece arriba:
URL:
http://localhost/Symfony/web/app_dev.php/demo/hello/Fabien
¿Qué está pasando aquí? Analicemos el URL: app_dev.php: Este es un controlador frontal. Es el único punto de entrada de la aplicación y responde a todas las solicitudes de los usuarios; /demo/hello/Fabien: esta es la ruta virtual al recurso al que el usuario quiere acceder. Su responsabilidad como desarrollador es escribir el código que correlaciona la solicitud del usuario (/ demo/hello/Fabien) con el recurso asociado (la página HTML de Hello Fabien!).
enrutamiento:
rutas Symfony2 la petición al código que se encarga de que al tratar de coincidir con la URL solicitada en contra de algunos patrones configurados. Por defecto, estos patrones (llamados rutas) se definen en el archivo de configuración app/config/routing.yml. Cuando se encuentra en el entorno de desarrollo, indicado por la aplicación dev Controlador frontal .php: también se carga el archivo de configuración app/config/routing_dev.yml. En la edición estándar, las rutas a estas páginas "demo" se colocan en ese archivo:
_welcome:
pattern:/
defaults: { _controller: AcmeDemoBundle:Welcome:index }
controlador:
Symfony2 elige el controlador basado en el valor _controller del enrutamiento configuración: AcmeDemoBundle: Bienvenido: índice. Esta cadena es el nombre lógico del controlador, y que hace referencia el método indexAction de la clase Acme \ DemoBundle \ Controller \ WelcomeController:
class WelcomeController extends Controller
{
public function indexAction()
{
return $this->render('AcmeDemoBundle:Welcome:index.html.twig');
}
}
Vista:
El controlador hace que la src/Acme/DemoBundle/Resources/views/demo/plantilla hello.html.twig
{% extends "AcmeDemoBundle::layout.html.twig" %}
{% block title "Hello " ~ name %}
{% block content %}
<h1>Hello {{ name }}!</h1>
{% endblock %}
Quizás también desee probar Symfony2 architecture
- 1. Mejor flujo de trabajo con Git & Github
- 2. Mejor flujo de trabajo PHP
- 3. Flujo de trabajo de Erlang
- 4. Git flujo de trabajo básico
- 5. Flujo de trabajo de subprogramas de Git
- 6. ¿Flujo de trabajo eficiente de Clojure?
- 7. Problemas con el flujo de trabajo de desarrollo de Sass
- 8. Compilación de flujo de trabajo con control de versión
- 9. JIRA, agregue un flujo de trabajo a un esquema de flujo de trabajo?
- 10. Flujo de trabajo Sharepoint frente al flujo de trabajo de Windows
- 11. Flujo de trabajo de IPython (editar, ejecutar)
- 12. Flujo de trabajo de Django al modificar modelos con frecuencia?
- 13. ¿Mejores prácticas de flujo de trabajo con git y github?
- 14. Flujo de trabajo de desarrollo web SVN
- 15. Git, SVN y Eclipse flujo de trabajo
- 16. Flujo de proceso/trabajo en Java
- 17. Prueba de unidad de flujo de trabajo
- 18. Flujo de trabajo de prueba de Haskell
- 19. Flujo de trabajo estándar cuando se trabaja con JPA
- 20. ¿Su flujo de trabajo i18n en Rails con TextMate?
- 21. ¿Funcionará este flujo de trabajo git-svn?
- 22. ¿Qué motor de flujo de trabajo elegir?
- 23. Flujo de trabajo de MDM en Android
- 24. ¿Flujo de trabajo de Python 3?
- 25. Flujo de trabajo UTF8 PHP, MySQL resume
- 26. Flujo de trabajo usando virtualenv y pip
- 27. Eclipse EGit flujo de trabajo recomendado
- 28. Flujo de trabajo XAML Intellisense VS 2010
- 29. Flujo de trabajo de documentación de Sphinx y JavaScript
- 30. Flujo de trabajo de prueba de Shoulda desde las trincheras