Bueno, llegó el momento de tener un poquito de tiempo y responderte un poco sobre las cuestiones que mencionabas acá en este Post. Lástima que tuve que ir a rescatar este Thread a la página 7 dos posts antes de que pasara a la 8 :D
1) Sobre el utilizar un Observer para relacionar acciones, como que no me gusta mucho esa solución, porque no favorece la "Carga Perezosa" (o existe algún otro nombre para la Lazy Load"?), por lo que ya deberías tener una instancia en memoria de cada Objeto que es factible de "oir" un evento del Observable. No no... no me gusta. Yo preferería que la interacción entre acciones se de más que nada utilizando un espacio en común, como pueden ser los Objetos Response y Request a los que tienen acceso todas las acciones.
2) Me gustó particularmente lo de la FullScreenView, pero más que nada porque es solamente interés de la vista el poseer un Layout o no, nunca debería ser menester del Controlador, el saber si tiene una vista relacionada o no. En este tema, podemos decir que Portlet o Boxlet pueden ser herederas de FullScreenView o pueden ser hijas de alguna vista que ontenga un layout ya predefinido ( en este caso el Box en particular ).
3) Particularmente, sabes por qué no me gusta que una Acción devuelva una instanciade una vista, y muchisimo menos 1 sola vista con el mismo nombre de la Acción ? Primero, porque eso me "ata" o me restringe a usar solo 1 vista por Acción, lo cual no es siempre lo que sucede, ya que en una acción, dependiendo del flujo del programa, puede devolver una u otra vista (completamente diferentes para los mismos datos, o quizás completamente diferentes debido a un error ). Más aún, es posible que haya Acciones que NO necesiten una vista, y que solamente ejecuten una acción y luego hagan un forward hacia otra acción que si devuelva una vista. Es por este tipo de cuestiones que inicié este Thread en un comienzo y terminé decantando por devolver el nombre de una vista en lugar de una instancia. Para tener un poquito más de Flexibilidad.
4) Sobreescribir un constructor no representa que se llame automáticamente a los constructores de las clases padre. Esto hay que hacerlo manualmente hasta que tengamos a PHP5 y sus métodos __construct con nosotros. Pero si dentro de un constructor, podemos hacer lo siguiente:
Código PHP:
<?php
function VistaConcreta ( $param )
{
parent::VistaBase( $param );
}
?>
Lo podemos hacer como primer comando o como ultimo comando, pre ejecutando código propio de la clase heredera antes que el código de la clase heredada.
5) Crear una instancia de CADA acción posible y almacenarla en un objeto está simplemente MAL. Se que venís de un ambiente como Java, en el que tenés una VirtualMachine constantemente corriendo, pero instanciar cada una de las "posibles" acciones, de las cuales con suerte se van a ejecutar una o dos, es un terrible OVERHEAD para cualquier aplicación. Sobre todo a medida que comience a crecer y tengas unas 20 o 30 acciones posibles. Es consumir muchisima memoria y recursos ( accesos a disco, etc ) para tan solo utilizar 1 de esas acciones.
Lo que yo hice para las Factorias, es que reciben el nombre del modulo y de la accion que necesitan devolver, se fijan en el FileSystem si existe el archivo correspondiente, y Si y Solo si el archivo es legible, lo incluyen e instancian la clase que tiene el mismo nombre que la acción que pedí, y retornan una referencia a esta instancia. De esta manera, solo tengo en memoria las acciones que necesito para ese Request en particular. Lo mismo hago para el ViewFactory.
6) Evita lo más que puedas los archivos de configuración, salvo para temas realmente pertenecientes a una Aplicación en particular ( y por aplicación, me refiero a alguna que se base en el FW, ya que varias podrán hacerlo ). Y para este tipo de cosas, yo suelo preferir los archivos de PHP, con constantes definidas, o a lo sumo, una opción que me gusta ultimamente, es la de utilizar archivos.ini y luego leerlos con PHP, incluso permitiendo de ser necesario, uno o varios de estos archivos por cada Modulo de una aplicación, dependiendo de los objetos que haya. Pero ya comenzar a utilizar XML para esto, es medio pesado o yo al menos no preferiría hacerlo sino hasta que el soporte de XML sea más estable en PHP5.
7) En cuanto a las vistas, las que mencionas en el último post de que necesitás 3 diferentes Themes para una aplicación, te comento mi opinión al respecto ( tan válida como la de cualquiera ):
Definitivamente tener 3 controladores, uno por cada "Layout" de tu aplicación, no es lo que yo utilizaría para resolver el problema, ya que siempre tendrias al menos 2 controladores instanciados que no se utilizan. Quizás si tu server es un Pentium Xeón con 4 procesadores de 3 Ghz y 4 gigas de RAM ( como el que todos tenemos en casa :) ) no sea un problema, pero teniendo en cuenta que algunos webservers no cuentan con esa tecnología, hay que pensar las cosas teniendo en cuenta un poco más la eficiencia. ;)
Entonces, para aplicar 3 Layouts distintos, yo haria lo siguiente ( esto es solo idea, nunca hice codigo sobre esto ):
- Defino una jerarquía de directorios, al estilo : /templates/nombre_layout/, para que todos los templates de las vistas en común, estén en /templates y los templates para los Layouts particulares, estén cada uno en su directorio.
- Se instancia 1 solo controlador, que llama a una Acción. La Acción hace lo que mejor sabe hacer ( instancia modelos, los manipula ) y devuelve el nombre de la vista a utilizar llamando a un método del "Controlador" que se llame... no sé... usarVista() ( que original que soy)
- Este método, dentro del Controlador, revisa que Layout es el que se está utilizando, ya sea por medio del Obejto Request, por Cookies, por Sesiones o por archivo de configuración, pero el tema es que estas tareas son las que le corresponden al Controlador. Entonces, luego de saber que Layout utilizar, llama al ViewFactory pasándole los parámetros que necesita ( modelo, vista ) y además, el layout a utilizar. El Factory entonces, podría instanciar una VistaFullScreen, pasarle el directorio que le corresponde al Layout, instanciar una vista concreta pedida por la acción, y asignar esta a la Vista FullScreen y devolverla al Controlador.
- El Controlador en este caso, recibe una VistaFullScreen y llama a su método renderizar(), que bien la Vista sabrá que hacer en este caso, ya que es su menester. Sin importar que se utilice un motor de Templates, XML+XSLT o lo que sea, la Vista se ejecuta a las vistas que tenga dentro relacionadas, y devuelve la página a mostrar.
- El usuario ve la página en la pantalla, ignorando de la danza de objetos que fue necesario para eso, esboza una sonrisa. Todos somos felices.
Bueno... esos fueron mis comentarios al respecto, se que a lo largo de este Thread se ahunaron varios temas diferentes, y no estaria en desacuerdo si se decidiera partir este Thread en varios otros.
Un Saludo.