with strip_tags remove quitar para funcion etiquetas ejemplo php kohana hmvc

php - remove - strip_tags wordpress



¿Cuál es el patrón de HMVC? (5)

Actualmente estoy en el proceso de desarrollar mi propio framework PHP 5.3 HMVC llamado Alloy . Dado que estoy fuertemente involucrado y vendido en HMVC, pensé que podría ofrecer un punto de vista diferente, y quizás una mejor explicación de por qué debería usarse HMVC y los beneficios que aporta.

El mayor beneficio práctico de utilizar una arquitectura HMVC es la "widgeization" de estructuras de contenido. Un ejemplo podrían ser los comentarios, las calificaciones, las pantallas de alimentación RSS de Twitter o blog, o la visualización del contenido del carrito de compras para un sitio web de comercio electrónico. Esencialmente, es una pieza de contenido que debe mostrarse en varias páginas, y posiblemente incluso en diferentes lugares, según el contexto de la solicitud HTTP principal.

Los marcos MVC tradicionales generalmente no proporcionan una respuesta directa para este tipo de estructuras de contenido, por lo que la gente generalmente termina duplicando y cambiando diseños, utilizando ayudantes personalizados, creando sus propias estructuras de widgets o archivos de biblioteca, o extrayendo datos no relacionados del principal solicitado Controlador para avanzar a la Vista y renderizar en forma parcial. Ninguna de estas opciones son particularmente buenas, porque la responsabilidad de presentar un contenido en particular o de cargar los datos requeridos termina filtrándose en múltiples áreas y se duplica en los lugares donde se usa.

HMVC, o específicamente la capacidad de enviar subpeticiones a un controlador para manejar estas responsabilidades es la solución obvia. Si piensas en lo que estás haciendo, se ajusta exactamente a la estructura del Controlador. Necesita cargar algunos datos sobre comentarios y mostrarlos en formato HTML. Así que envía una solicitud a los comentarios Controller con algunos parámetros, interactúa con el Modelo, elige una Vista y la Vista muestra el contenido. La única diferencia es que desea que los comentarios se muestren en línea, debajo del artículo del blog que está viendo el usuario en lugar de una página de comentarios completa completamente separada (aunque con un enfoque HMVC, puede atender solicitudes tanto internas como externas con el mismo controlador y "matar dos pájaros de un tiro ", como dice el refrán). En este sentido, HMVC es simplemente un subproducto natural de la búsqueda de una mayor modularidad de código, reutilización y una mejor separación de las preocupaciones. ESTE es el punto de venta de HMVC.

Por lo tanto, aunque es interesante pensar en el artículo de Sam de Freyssinet sobre TechPortal para escalar con HMVC, no es donde el 90% de las personas que usan marcos de HMVC obtendrán beneficios reales, prácticos y cotidianos.

Al leer la documentación de Kohana, descubrí que la principal diferencia en la versión 3.0 es que sigue el patrón HMVC en lugar de MVC, como lo hace la versión 2.x. La página sobre esto en los documentos de Kohana y la de wikipedia en realidad no me dieron una idea clara.

Entonces, pregunta: ¿cuál es el patrón HMVC y cómo difiere de MVC?

En Kohana, al menos, una solicitud HMVC es una solicitud HTTP a la que se da servicio "internamente": en lugar de emitirse a través de la red, es enrutada, despachada y manejada por el propio marco. La similitud de los nombres "HMVC" y "MVC" es confusa, ya que sugiere una conexión subyacente entre los términos que de hecho no existe: uno no es una variante menor o modificación del otro, son cosas completamente diferentes. (HMVC también se describe como Ajax sin la solicitud HTTP del lado del cliente). El énfasis de Kohana y el soporte para "HMVC" significa que el marco tiene un fuerte soporte para una arquitectura orientada a servicios basada en HTTP.

La ventaja de este patrón arquitectónico es que, dado que la misma "convención de llamadas" se usa para solicitudes internas y externas, es trivial convertir solicitudes de servicio "internas" a solicitudes "externas" o viceversa, según sea necesario.

Si bien este es un patrón arquitectónico sensato, parece innecesario darle su propio nombre (Symfony2 describe el mismo concepto de " sub-requests "), y de hecho el nombre parece ser un nombre inapropiado: no hay un requisito particular o la necesidad de que las solicitudes formen un jerarquía (que no sea el gráfico de llamadas estándar de cada programa imperativo); las solicitudes podrían ser fácilmente recursivas, por ejemplo.

[ Actualización de abril de 2011, marzo de 2012: ampliada en respuesta en respuesta a los comentarios.]

HMVC es Controlador de vista de modelo jerárquico. En MVC normal, cada objeto de GUI tiene su MVC. Sin embargo, no existe ninguna relación entre el objeto de la GUI principal y el objeto de la GUI secundaria a diferencia de HMVC. En HMVC, cada objeto GUI tiene acceso a sus objetos secundarios y cada uno de los objetos secundarios puede acceder a su objeto principal.

Entonces en cada vista hay una vista principal. A través de la cual puede acceder a su vista principal. Porque en cada controlador hay un controlador padre a través del cual puede pasar el evento al controlador principal (si el evento no está en su alcance).

Para la descripción de los detalles, haga clic here

Nuevo enlace es here

HMVC está estrechamente relacionado con el enfoque "basado en componentes" para el despacho. Básicamente, en lugar de tener un único despachador, que delega en un controlador, cada controlador puede actuar como un despachador. Esto le da una jerarquía de controladores. El diseño es más flexible y provoca una mejor encapsulación del código, pero a un precio de mayor abstracción. Konstrukt está diseñado alrededor de este patrón.

Ver también esta respuesta: https://.com/questions/115629/simplest-php-routing-framework/120411#120411