11

Estoy tratando de identificar algunos de los pros y los contras de tener un CMS impulsado por eventos.CMS orientado a eventos: ventajas y desventajas

Evento controlado no es infrecuente. Lo ves en muchos lenguajes de scripting como Actionscript, javascript, jquery que involucran a un cliente. ¿Qué tal en un CMS donde los eventos y sus respuestas suceden en el servidor? ¿Qué ventajas o desventajas tiene este enfoque y qué otros enfoques existen para que las personas prefieran más?

P.S. Tenga en cuenta que uso Actionscript, JQ y JS solo como ejemplo. Te das cuenta de que cuando se habla de un CMS de esta manera, los eventos y sus respuestas son todas cosas del lado del servidor.

Editar: Veo mucha gente que dice que no tiene sentido usar orientada a eventos, ya que no consiguen lo que es. Uno de los sistemas CMS que ya usan este enfoque es Drupal, así que créanme que es una forma existente, no estoy extrayendo ideas de mi A. Simplemente significa las "partes internas" del CMS (todas las cosas del lado del servidor) son impulsados ​​por eventos. El núcleo hace lo suyo Y define eventos. Los complementos pueden responder a esos eventos para agregar su propia lógica. Menciono Actionscript como ejemplo porque el lado del cliente es donde este concepto es más conocido, pero también puede estar del lado del servidor, tal vez no sea tan relevante para las aplicaciones normales y, por lo tanto, no tan conocido. Pero tiene sentido algo más complejo como un CMS donde otros desarrolladores quieren agregar sus propios complementos o incluso cambiar la lógica preconstruida del CMS.

+1

¿Qué ventaja está buscando en este enfoque? Cuando dices CMS, supongo que te refieres a un CMS basado en web. Independientemente del software del lado del servidor, su CMS respondería a las solicitudes HTTP, generará html y lo devolverá al cliente, ¿verdad? Entonces, ¿cómo ayudaría un evento impulsado por CMS en ese proceso? – marcvangend

+0

Me tomé la libertad de poner tu actualización en un bloque de comillas y deshacerlo. Siéntase libre de retroceder si no le gusta. –

+0

¿Qué idioma usarías entonces? @Georg, ¡qué perspicaz de tu parte! :) Me parece razonable preguntar cuando todos los ejemplos que se proporcionan son idiomas del lado del cliente y, por lo que sé, PHP no distribuye eventos, sin la ayuda de ninguna biblioteca adicional. Además, con una reputación de más de 17k, usted debería ser capaz de aportar algunas respuestas a la pregunta usted mismo, ¿no es así? Entonces, Georg, ¿qué idioma crees que debería usar Dave? – PatrickS

Respuesta

1

¿A qué se refieren exactamente por "event driven"? ¿Significa eso que los clientes pueden mirar el contenido y recibir una notificación cuando se actualice?

Si es así, esto es realmente una gran idea, pero la implementación es una experiencia ambiciosa. La clara desventaja es que hay toneladas de cosas que pueden salir mal, mientras que un modelo basado en solicitudes es mucho más simple y, por lo tanto, más robusto.

+0

Significa que las "partes internas" del CMS son impulsadas por eventos, al igual que Drupal lo hace. El núcleo define eventos y los complementos pueden responder a ellos para agregar su propia lógica. – dave

6

¿Estás seguro de que "dirigido por un evento" es el término correcto para esto?

Creo que de lo que estás hablando es de una infraestructura de enganche de complemento que permite que los complementos actúen cuando se produce un evento (se activa un enganche).

Lo que conozco como "impulsado por eventos" es cuando las aplicaciones de escritorio almacenan eventos en elementos de la interfaz de usuario, al igual que Javascript puede hacer para elementos HTML. Las aplicaciones de escritorio están construidas completamente de esa manera. Eso nunca se puede lograr en PHP basado en web porque está completamente orientado a solicitudes.

De todos modos, veo lo que quieres decir ahora. Hay CMS y marcos que tienen esto hasta cierto punto: Wordpress, por ejemplo, y Dokuwiki.

Además:

estoy tratando de identificar algunos de los pros y los contras de tener un CMS que es el evento impulsado.

Los pros son obvios: se vuelve mucho, mucho más fácil conectar el sistema sin tener que hackear el núcleo. Se hace posible escribir complementos reales.

Una gran desventaja es que el sistema tiende a ser más lento a largo plazo cuanto más ganchos hay, y más plugins se registran en los ganchos. He visto una gran operación de mantenimiento del portal, la eliminación de varios cientos de nodos Drupal, tome horas en un servidor de producción ultrarrápido, principalmente debido al sistema de enlace.

+0

+1. La infraestructura del complemento (enlace) suena bien y se explica por sí misma. La wiki es bastante clara sobre lo que "impulsa el evento": http://en.wikipedia.org/wiki/Event_driven_programming. Y no hay ningún bucle principal en PHP :) – back2dos

+0

Estoy de acuerdo, Drupal y Wordpress fácilmente se convierten en grandes elefantes de grasa lenta a medida que agrega más y más módulos/complementos. He visto sitios con cientos de módulos/complementos que tienen que escalarse con varios servidores, equilibradores de carga y cachés frontales porque el CMS no puede mantenerse al día con solo unos pocos visitantes. Agregar funciones es tan fácil para los diseñadores de sitios web y para los desarrolladores es tan fácil aprovechar otros módulos (he visto módulos drupal muy simples con docenas de dependencias, ahora imagino que instalas una docena de ellas). –

Cuestiones relacionadas