Observer está bien, pero tendrá que considerar ir más allá del patrón básico. El patrón canónico Observer/Subject solo envía el objeto Subject al Observer, nada más, ni siquiera por qué está siendo notificado.
Inicialmente, la solución puede parecer que también incluye el motivo de la notificación al observador, pero luego puede terminar notificando a los observadores que no se preocupan por ciertas notificaciones. Una mejor solución podría requerir que los observadores también soliciten una lista de notificaciones que les gustaría recibir.
Pero eso también presenta un problema. Para que los observadores se unan realmente a los sujetos, deben ser instanciados. Cada vez. Incluso si nunca serían necesarios. Eso es tonto.
Por lo tanto, hemos llegado rápidamente a una de las implementaciones PHP canónicas de complementos: "ganchos". Los ganchos usan el mismo concepto que Observer/Subject, pero la implementación es diferente de una manera muy importante: los observadores reales no se crean instancias para observar sujetos. En cambio, los sujetos envían una notificación a alguna variedad de repositorio central. Este repositorio está configurado con una lista de todos los complementos instalados y activados (Observadores), y contiene una lista de todos los eventos que cada plugin desea recibir. Cada complemento se notifica solo cuando se produce el evento, a menudo a través de un método estático en lugar de crear una instancia del complemento y notificarlo. call_user_func_array y un buen autocargador lo hace increíblemente trivial.
Por lo tanto, puede crear una interfaz simple para todos los complementos a implementar. Los métodos que usted necesita incluyen pero no se limitan a:
- Algo para obtener los datos sobre el plugin, tales como su nombre, autor, sitio web oficial, la versión, etc. Humana información consumible.
- Un método que devuelve los eventos a los que el complemento desea suscribirse.
- Método de instalación, para cosas que el complemento necesita hacer para instalarse, como manipular la base de datos.
- Un método de desinstalación también puede ser útil.
- El método (probablemente estático) que recibirá notificaciones de eventos y devolverá los datos que sean necesarios.
Dependiendo de qué tan lejos tome el concepto de complemento, podría terminar con complementos que tengan opciones configurables por el usuario. Es posible que deba tener eso en cuenta. En ese camino yace la locura y los sistemas de configuración.
Para que los complementos entren en vigor, necesitará colocar los ganchos en todas partes, y con frecuencia trabajará con los usuarios finales para agregar nuevos ganchos donde sean necesarios.
Los widgets pueden funcionar fácilmente de manera similar, como los complementos que se llaman antes de la representación de la página.
Temas/plantillas, oh mi. Probablemente tengas dos grandes opciones.
- Smarty, o un motor de plantillas similar. O su propio motor de plantillas no PHP.
- Plantillas de PHP.
Esta decisión estará dirigida por sus usuarios finales. Smarty es increíblemente limitante, pero si quiere asegurarse de que solo el código aprobado se ejecute en una plantilla, podría ser una opción viable. Además, no es inseguro permitir la edición de plantillas Smarty directamente en la propia aplicación.
Por otro lado, una de las razones por las que las plantillas de Wordpress funcionan tan bien es que son PHP puro. Pueden llamar a cualquier método expuesto en la API de Wordpress e incluso pueden hacer su propia lógica interesante. Si espera que sus usuarios finales tengan una mente técnica, o al menos sean técnicamente competentes, entonces las plantillas PHP son el camino a seguir. Por otro lado, permitir la edición de plantillas PHP dentro de la aplicación puede abrir un enorme agujero de seguridad potencial si un usuario malintencionado entra en los bits de administración. Probablemente desee restringir la edición al sistema de archivos.
Si bien esto cubre la creación de HTML, también debe tener en cuenta CSS. ¿Sus usuarios finales podrán manipular CSS directamente? ¿Querrán ellos? Si sus plantillas predeterminadas incluyen suficientes clases semánticas, probablemente puedan hacer una gran cantidad de estilos sin mucho esfuerzo, si saben lo que están haciendo. Por otro lado, es posible que los usuarios finales no sepan qué es CSS, por lo que es posible que deseen, por ejemplo, selectores de color y combinaciones de colores preconstruidos, y un selector de esquema de colores, y otras cosas tan molestas de construir. Probablemente sea mejor pensar en esos horrores ahora.
Cosas varias.
Ningún CMS estaría completo sin el concepto de borradores y estados de publicación. No tengo ningún consejo para usted aquí, que no sea codifique este primer. Si su cliente o los usuarios finales desean algún tipo de archivado histórico, mecanismo de aprobación gerencial o cualquier otra cosa que haga de borrador/publicado cualquier cosa que no sea un campo de estado simple, necesita saberlo muy pronto. (He sido mordido horriblemente por este.Diseñamos todo el sistema en torno a un modelo simple publicado/no publicado, y obtuvimos unos 9/10 mediante la creación de especificaciones y el código de prototipo relacionado cuando nos dimos cuenta de que no funcionaría y tendríamos que hacer algo mucho, mucho más. complejo para cumplir con los requisitos del cliente. Reconstruir el plan preliminar fue el mayor sumidero de tiempo que hemos encontrado hasta ahora.)
¿Usará un ORM? Si no, asegúrese de usar una biblioteca de interfaz de base de datos adecuada. PDO, o tal vez algo de PEAR, o tal vez Zend_Db. Inevitablemente tendrá un cliente que insista en que el código se ejecute en Oracle o MSSQL. O SQLite. Será bueno decirles que se puede hacer (con un poco de esfuerzo). Los autores de plugins también te agradecerán por la cordura. No haga haga la suya.
(Por otra parte, con su nivel de representante, espero que ya esté familiarizado con casi todo lo que he dicho. Ah, las cosas que hago para distraerme mientras pienso en mi propio conjunto de problemas de codificación ... .)
curioso ... ¿Alguna razón por la cual un cms existente (como drupal) no puede extenderse para hacer lo que usted quiere? – xenoterracide
@xenoterracide: Es requisito del cliente crear un nuevo sistema CMS dirigido a actores y cantantes y entidades similares de los medios. – Sarfraz
http://journal.relativesanity.com/2008/11/17/how-not-to-build-an-in-house-cms/ –