Real World MVC - Tratando con formas

Question

Todavía estoy algo confundido por cómo se supone que MVC funciona.

Digamos que tengo un sitio web que vende widgets. Tengo una página de listado, /widgets/list y una página de producto /widgets/product/123.

Ambos pueden usar el controlador widget y llamar a los métodos list y product - lo suficientemente simple hasta el momento. Digamos que también tengo varios otros controladores para varias cosas.

Ahora agrego un cuadro de registro de boletín en mi encabezado, es decir, en cada página del sitio. ¿Cómo va a funcionar esto? Me da la idea de que debe enviarse al /newsletter/signup

Pero, ¿qué sucede si hay un error (digamos que no completó su dirección de correo electrónico correctamente)? Debería mostrar la página en la que estaba (por ejemplo, /widgets/list), pero el controlador newsletter debe ejecutarse. El controlador widget no conoce el controlador newsletter por lo que no puedo poner el código allí ... ¿Cómo se supone que funciona?

Editar: No AJAX por favor - Puedo entender eso más fácilmente. Considere esto como la alternativa cuando javascript está deshabilitado.

Edición 2: ejemplos o tutoriales que cubren este tipo de cosas se agradecería mucho

Datos 3: ¿Es permisible para el fin de llamar a una acción? Por ejemplo, el encabezado podría llamar a Newsletter->index()

Answer 1

Debe colocar el mensaje de error en algún lugar global donde el controlador de página (que incluye los "subcontroladores" newsletter) puede recogerlo.

En caso de AJAX, puede hacer que el controlador newsletter hable con el DIV en el que está visible (ya que no está recargando toda la página). Para eso, necesitarás un fragmento de JavaScript en la página que se llama cuando finaliza la solicitud AJAX, que toma la cadena y la coloca donde quieras.

Answer 2

Mi experiencia MVC es más práctico y menos "lo que dice el libro", pero aquí va:

Tendrías una clase de controlador de base (en CakePHP - que es lo que estoy más familiarizado - es llamado AppController) que está subclasificado por todos los demás controladores. Esta clase implementaría todas las cosas "globales" de las que estás hablando.

Ejemplo práctico:

En mi clase AppController, el marco define una devolución de llamada beforeFilter() que se ejecuta en esencia en cada carga de la página. Aquí es donde verificaría si el formulario de suscripción se había enviado y lo manejaría de manera adecuada. Si el registro tomaba una mierda de alguna manera, agregaba algo a la sesión que indicaba tanto y mi vista simplemente verificaba la existencia de una lista de errores que se originaba en el modelo del boletín informativo y, si estaban allí, los mostraba.

Esto es probablemente un poco más pesado en las tuercas y pernos y más ligero en la teoría de lo que estaban pidiendo, pero no tengo ningún entrenamiento formal en cualquiera de esta basura por lo que no es mi mejor :)

Answer 3

Agregar un campo a la formulario de boletín, que almacena la URL de la página actual. Cuando se produce un error durante el envío del boletín, recupere la URL y redirija a esa página. Siempre que coloque la información de error en el lugar correcto, debe recogerla mediante el formulario del boletín que, según usted, está incluido en cada página.

Answer 4

Para widgets que se supone que devuelven algunos errores de validación, etc. - use partial requests (o los subcontroladores de MvcContrib) + AJAX.

Answer 5

Lo que hago es que cada formulario se publique solo. En el controlador, verifico si la variable de publicación está configurada; si es así, hago la validación. Si la validación tiene éxito, hago un redireccionamiento a otra página. Si falla, la página de formulario se vuelve a cargar con mensajes de error. Esto lo hace fácil y reduce la duplicación de código. Vea aquí:

**in controller**: 

If post variable is set: 
    validate form 

    if form is validated: 
     redirect to new page (or whatever) 
    else: 
     add error messages to the $data variable of the view 
    endif 

endif 

//$data contains whatever information you'd normally pass to the view. 
//if there was a validation error, the messages are added to the $data variable 
show view with $data variable 

Como puede ver, el flujo siempre se reduce a la instrucción de carga de vista única. Sin embargo, si la validación es exitosa, te llevarán a otra página.

Answer 6

No veo por qué el mensaje de error para el boletín informativo que está en cada página, debe mostrarse en la misma página. Si tiene una página que se publica en otra acción, sin relación con la vista actual (por ejemplo, búsqueda), entonces no hay razón para que se muestre el mensaje de error en la página original. ¿Mostrarías el mensaje de éxito en la misma página? ¿Dónde se manejaría eso?

Los mensajes de error para el formulario del boletín deben mostrarse en una vista dedicada al boletín. Por ejemplo, vea cómo se hace en Stackoverflow: ingrese en el cuadro de búsqueda y no escriba nada, simplemente presione enter. Este es un tipo de error ya que no especificó lo que quiere buscar. Stackoverflow lo llevará a una página diferente que explica cómo funciona la búsqueda.

¿Ahora por qué hizo eso? La razón es simple: el usuario estaba en una página y elegido para participar en una actividad que no está relacionada con la página actual, por lo que no hay motivo para mantenerlos allí.

Answer 7

¿Qué le parece agregar un campo oculto a la página que se envía al controlador/newsletter/signup con la url de dónde ir después de que el controlador finalice, es decir, la página actual (o podría usar el encabezado http del referer).

Este controlador luego agrega una lista de mensajes de error o un mensaje de éxito a una lista de objetos para ser renderizados por la vista antes de reenviar al controlador especificado por el campo oculto anterior. Este controlador luego agrega su lista de objetos que se mostrarán en la vista (por ejemplo, lista de widgets).

Luego, en la vista, puede mostrar los mensajes de error del controlador del boletín de noticias, si está presente.

Answer 8

Hay una buena ASP.net MVC centrada tutorial que describe los métodos para incluir widgets (componentes reutilizables) en un entorno MVC.

La idea básica es configurar widgets con su propia canalización de solicitudes, no fusionarlos en un controlador/vista combinados que anularía la capacidad de mantenimiento de MVC.