Que hago con esta Vista? (un poco de POO)

[Webstudio]

Que tal gente. Estoy aqui haciendole una consulta a la gente que esté un poco más acostumbrada a realizar desarrollos orientados a objetos. Resulta que para un cliente, he desarrollado un mini-Framework basado en algunos patrones de diseño comunes: FrontController, Command, MVC, etc.
El caso es que estoy trabado en una parte y quisiera que me dieran sus opiniones. El flujo de trabajo es asi...

Todos los pedidos se atrapan en la misma url, por ejemplo, index.php. Este archivo, instancia un FrontController, que se encargará de determinar, que Acción se debe ejecutar. La acción, no es más que un objeto de la SubClase Accion, que recibe los datos de los parámetros y trabaja con ellos, determinando que objetos Modelo instanciar y que Vista se debe utilizar para presentar los datos.

- FrontController recibe los parámetros del usuario ( en un objeto wrapper que llamaremos Request ).
- FrontController instancia un objeto de la clase Accion ( pasandole Request como parámetro ).
- Se ejecuta el método "ejecutar" del objeto Accion con la lógica de 1 comando en particular.
- Este comando, instancia y utiliza los objetos de Dominio para realizar la tarea que se supone que tiene que hacer ( contabilizar un voto, mostrar un Thread, lo que sea ).

Mi problema llega en el momento de trabajar con la devolución al navegador. Debería el objeto Acción, instanciar un objeto Vista (View) y retornarlo al FrontController? Debería el objeto acción retornar solo el nombre de la vista a utilizar, y que el FrontController instancie la Vista necesaria ( a través de un Factory ) ?.
Qué es lo que a criterio de Uds. sería mejor para mantener una buena separación de capas?

Cómo lo tenía pensado hasta hace poco, era que el Objeto Acción, luego de instanciar los objetos modelos necesarios y de incluirlos en un objeto "Response", instanciara el objeto Vista necesario, le pasara el objeto Response como parámetro y lo retorne al FrontController. Y ya...

Pero luego pensé que posiblemente, una mejor separación se podría lograr al hacer que el Objeto Acción ( que en definitiva es un Controlador ) , retorne el nombre de la Vista a utilizar, y que el FrontController decida que tipo de Vista instanciar ( HTML, XML, WAP, lo que sea) basado en el nombre que la acción le devuelve.

Bueno... ya no sigo por si alguno está más que mareado, tan solo espero que me hayan podido entender y que me den sus opiniones, si alguno cree que necesita algo más de introducción al contexto del problema, me avisa y sigo.

un saludos para todos.

[Cluster]

Hola Webstudio ...

Bueno .. aunque como dices la pregunta va orientada a personas que se manejan con OOP (no es mi caso :( ..) .. pódrías si quires continuar con la "introduccion al contexto del problema" .. por lo menos para que personas como yo que no uso OOP (bueno .. uso algunas classes pero no 100% OOP) nos sirva para ver como "se debe" hacer las cosas bien.

Un saludo,

[vitxo]

Hola Webstudio,
yo tb uso un pequeño marco de trabajo casero basado en el patrón MVC.
También tengo una serie de Acciones y Vistas. A cada acción le corresponde una vista, normalmente (porque podría tener una vista sin una acción asociada, una especie de "portlet").
Tengo un controlador que instancia para cada petición una acción y una vista. (aproximadamente, en realidad instancio todas las clases una sola vez pq mi controlador impementa un Singleton).

Estas acciones tienen un método que yo he llamado "process" que contiene la lógica correspondiente y que recibe por parámetros una instancia de una clase que encapsula los datos la petición y de la respuesta HTTP. (HttpData)
En el método process recojo los parámetros de la petición del usuario, los proceso, y los resultados se los devuelvo a esa clase mediante un típico método "javero" setAttribute( $key, $value ) (sí, lo almacena en un array asociativo).

Bien, he dicho q cada acción tiene asociada una vista, digamos que cada instancia Vista tiene un método que llama el controlador: render() que recibe por parámetros la misma instancia de HttpData, por lo que sólo tiene que invocar al getAttribute('clave') y actuar en consecuencia (instanciar el motor de plantillas y generar la vista correspondiente y devolverla, x ejemplo).

He aquí un trocito de código improvisado, del controlador:

Código PHP:

    $data =& new HttpData(); 
  $action -> process( $data ); 
  $results = $view -> render( $data ); 
  echo $results; 
  /*o expones $results a una plantilla del controlador que especifique el layout de la página*/  
   

Aunque también encuentro un dilema en cuanto a las vistas, no sé si es correcto devolver un String con la vista ya generada.

Me gustaría extenderme muchísimo más, pero mi descanso de estudiar ya se ha acabado :) (tengo mi último examen el próximo martes y estoy un poco acojonado con tanta integral y pollas )

Espero no haberme ido por las ramas, a este hilo se le puede sacar mucha chicha.

un saludete.

[vitxo]

Ahora que me releeo, no sé si termino de dejar claro la separación que tengo de mis acciones y vistas?

[Webstudio]

Vitxo, pues veo que los dos tenemos realmente acercamientos al mismo problema de maneras muy similares, tan solo que no me he explicado bien parece, ya que mi idea NO es devolver un String con la vista generada, sino que el objeto Accion, devuelva el NOMBRE de la vista que quiere utilizar ( "showthread", "threadfailure", lo que sea ). A esto me refería cuando hablaba de un String.

Y estoy evaluando esto ya que una Acción, dependiendo del flujo del código, puede determinar que tiene que mostrar una u otra vista, por ende, hacer una relación 1 a 1 entre acción y vista no me parecía adecuado.

Es por esto, que se genera el problema que me tiene en duda, ya que lo más sencillo sería que la Acción ( que en definitiva no es más que una extensión del controller ) devolviera ya la vista instanciada. Pero mi duda viene a que para determinar QUE vista es la que se debe instanciar, se debe acceder a información que está (o debería estar) en el Front-Controller, como puede ser las cabeceras Content-Type, Accept-Language, Encoding, etc.

Aparte de que pleaneo agregarle al Frameweork un FilterChain, para que se puedan ejecutar Pre-Filtros y Post-Filtros para manejar las tareas más típicas de la aplicación (Loggeo de errores, autenticación de usuarios, et ).

Sigo con el dilema, veremos que me dicen en algunas listas de correo que postié la misma pregunta, o en SitePointForums.

[vitxo]

Muy interesante Webstudio, estoy deseando terminar exámenes para meterle mano a estas cositas, y a mi PHPMarker de las narices

nos leemos, si tienes noticias avisa por aqui :D

[Webstudio]

Para Cluster y para el resto que estaba interesado en saber un poco más sobre el problema y como está compuesto el Framework que estoy haciendo, pueden ver información sobre el mismo en esta URL :

http://www.sitepoint.com/forums/show...26#post1097717

[Cluster]

Gracias, Webstudio ;)

Un saludo,

[vitxo]

ya sé que me repito más que el ajo, pero MOLA!

[Webstudio]

Mensaje Original por vitxo
ya sé que me repito más que el ajo, pero MOLA!

Me alegro que te haya gustado, de hecho está bastante siemple, porque no quiero que los objetos sean super cargados de métodos, ya que quiero que sea un Framework liviano porque hará uso de bastantes objetos.

De hecho, en la explicación puse los nombres de los objetos y métodos en inglés, pero en realidad los tengo la mayoria en castellano porque luego pienso lanzarel framework al público, más algunas explicaciones de que son los distintos patrones que uso, para que se entiendan las distintas partes que componen al mismo.

Ya que tu has estado haciendo algo similar... te molestaría postear los lineamientos básicos en código de tu Framework, para comparar y que todos salgamos beneficiados?

Saludos.

[vitxo]

Yo prefiero usar notación inglesa para programar, pues (por gracia o desgracia) el inglés es prácticamente universal.
A ver si esta noche pongo el esqueleto de mis clases, aunque si no lo hago esta noche lo haré el miércoles. (sí, mi examen de los cojj... las narices! )

De todas formas, yo no me preocupé de implementar una factoría de acciones/vistas, pues las almaceno en dos arrays asociativos del controlador. Porque también me preocupa "abusar" de los objetos, pero los patrones de diseño están para optimizar (o casi) su uso.

Si necesitas algún "beta tester" para leer una primera versión de "la teoría" de tu marco de trabajo cuenta conmigo, y si quieres yo te enseño la mía (la teoría de PHPMarker, cochino )

ciao!

[Webstudio]

Yo en realidad utilizo los nombres de Objetos y métodos en castellano, más que nada porque me interesa que mis objetos / aplicaciones los utilicen personas cuya lengua materna sea el castellano. Los sajones ya tienen bastantes buenos programadores programando solo en inglés. Aunque he de admitir que me cuesta terriblemente a veces encontrar nombres válidos, sobre todo para los métodos, en castellano, sin caer en el Spanglish.

El FrameWork está ya casi terminado en una fase Pre-Alpha... o sea... es usable, pero en el transcurso del tiempo le voy a ir agregando muchas cosas hasta que lo considere lo suficientemente estable. De todas maneras, aún no estoy completamente decidido de que manera implementaré unas cosas.... ya con el tiempo veré como lo hago.

A mi lo que me interesaría es ver, solo si es posible y no te molesta, el código del FW que dices haz hecho con Acciones y Vistas, solo para ahunar criterios.

El PHPMarker lo estuve revisando hace un tiempo cuando lo publicaste en SitePointForums y me pareció muy bueno, aunque me he reservado las opiniones en ese momento esperando tener más tiempo de revisarlo a fondo. Igualmente, para todo lo que sea trabajo con XML, tengo como cierta retiscencia a utilizarlo con PHP4, por lo menos sabiendo que PHP5 traerá mejor soporte nativo y podremos utiilzar DOM o SimpleXML de manera más transparente.

Pero bueno, cuando avance un poco más en esto, lo postearé aqui.
Saludos.

[vitxo]

No te preocupes, no te posteo el código ahora por varias razones: el examen de mañana y que estos días tengo pensado meterle mucha mano. Porque el domingo que viene tengo que dejar lista la web de las III Jornadas de Software Libre y la Linux Install Party que celebramos en marzo en mi universidad, y organizamos los de la Linuv (http://linuv.uv.es/, la asociación de usuarios de gnu linux de la universitat de valència). Así que a lo largo de esta semana te iré dando cosas conforme vaya tomando una forma decente.

En un principio el motor MVC lo hice para la web de la iParty del año pasado (http://linuv.uv.es/party , que no funciona muy bien porque hemos tenido problemas con el server últimamente y como todos estamos de exámenes nadie lo ha arreglao ), lo hice en pocos días y muy rápido así que tenía muchos apaños. Luego lo modifiqué para adaptarlo para la inscripción en el I Congreso de javaHispano celebrado hace unos meses (http://congreso.javahispano.org).
Finalmente espero dejarlo bastante bien maduro (bien definido con patrones ) para la iParty de este año. Entonces te lo pasaré

En cuanto a PHPMarker, estoy de acuerdo en que PHP5 va a suponer un gran avance. Aunque desde que hice mi primer post en SitePointForums hasta ahora el motor (de plantillas) ha cambiado muchísimo (a mejor, excepto en el rendimiento que tengo q revisarlo jiji), no sé si has visitado el CVS público (http://www.sourceforge.net/projects/phpmarker).
Porque lo que hay funciona, eso sí, me falta documentarlo como dios manda.
Antes de empezar exámenes empecé a escribir dos documentos: uno sobre cómo usarlo y otro sobre "cómo implementar un motor de plantillas y no morir en el intento" (nombre que parió josemi ).
Así que después de terminar todo "el trabajo de los webs" y de prepararme una charla de 1 hora y pico sobre el Modelo Vista Controlador para las Jornadas, los terminaré de escribir y continuaré con el desarrollo de PHPMarker.

Sí, soy un poco hiperactivo cuando me lo propongo. Y me doy cuenta que tiendo a llamarlo todo "motor"

me voy a seguir estudiando, que todavía le puedo sacar horas productivas a la noche!

nos leemos.


creo que no se me queda nada, empezaré a trabajar en el temita el miércoles, así que a partir de ahí postearé por aquí todas las ideas que alumbre

[vitxo]

Bien, ya he empezado a pasar el mini-framework a código (hasta ahora eran diagramas sobre papeles en sucio en pseudo UML, si es que se le puede llamar UML a lo que hice ). Todavía no he llegado al punto de que pueda implementar un HolaMundo, pero no me debe quedar mucho.
Por cierto, tiene muchísimo más sentido que la acción devuelva un objeto de la Vista, en vez de recuperar el String representativo desde el controlador.

Empezando de abajo a arriba, voy a tener dos jerarquías de objetos, unos hijos de AbstractAction y otros de AbstractDisplayer que esbozo a continuación (por cierto, para PHPMarker usé unos "TagHandlers" que se parecen mucho a esas clases ):

Código PHP:

  class AbstractAction { 
  function AbstractAction(){ 
  } 
  //me ayudará (re)iniciar el objeto cuando ya esté construido 
  function init(){ 
    trigger_error('llamada a método abstracto');     
  } 
  //recibe una instancia de WorkData (petición+respues HTTP) 
  function process( &$data ){ 
    trigger_error('llamada a método abstracto'); 
  } 
   //inicializará atributos de clase 
   //de forma que $key es el nombre del attr. 
   function addPropery( $key, $value ){ 
         trigger_error('llamada a método abstracto'); 
   } 
} 
 
class AbstractView{ 
  function AbstractView(){} 
  function init{} 
  function render( &$data ){} 
  function addProperty($key, $value){} 
}  
   

De tal forma que un supuesto HelloWorldAction heredará de AbstractAction y su correspondiente vista de AbstraView. Esto está claro.

A continuación el controlador, sólo pongo un método (porque los otros dos son el constructor "privado" y su corresondiente getInstance):

Código PHP:

  class Controller { 
  
  function init(){ 
    //esto se ejecutará una vez, cuando se invoque al constructor 
   //simplemente construye las factorías 
   //para no tener que hacerlo luego 
    ActionManager::getInstance(); 
    ViewManager::getInstance(); 
    TemplateManager::getInstance(); 
  } 
 
  function getView( &$data ){ 
        $mgr =& ActionManager::getInstace();         
        $action =& $mgr -> getAction( $data -> getParameter('action') ); 
        $view =& $action -> process( $data ); 
    $tmanager =& TemplateManager::getInstance(); 
        $tmanager -> setTemplateFactory('phpTemplate'); 
        $tmanager -> setTemplateDirectory('presentation/'); 
        $mainview = $tmanager -> getTemplate( 'layout', 'layout.html' ); 
    $mainview -> expose( 'view', $view) );         
    echo $mainview -> render(); 
  } 
}  
   

Cosas que comentar:
1. La forma de llamar al controlador es:

Código PHP:

  //index.php?action=helloworld 
$data =& new WorkData(); 
//sí, le cambié el nombre de HttpData 
$controller =& Controller::getInstance(); 
$controller -> getView($data)  
   

2. ActionManager crea y mantiene las acciones
3. Hay un ViewManager que usa cada Acción para recuperar la instancia de vista que le corresponde.
4. El TemplateManager a lo mejor os suena de PHPMarker, y es que enfecto, simplemente llamando a setTemplateFactory('phpmarker') el getTemplate() me devolvería una instancia que interpreta esa clase plantillas.
Pero como por lo pronto está en fase "experimental", uso una clase muy simple (como la del artículo de Sitepoint: beyond the template engine) que abstrae una típica plantilla con PHP para represenar la lógica de la presentación.
De esta forma, es posible usar cualquier motor de plantillas, siempre que se implemente una clase que herede de 'Template' y sobreescriba varios métodos, encapsulando la clase del motor de plantillas a usar (Smarty por ejemplo). No pongo el código ahora porque se me puede quedar inmenso el post.
Y así, trabajo de forma transparente independientemente de cómo sea la capa de la presentación y de qué formato escupa: HTML, PDF, XML... (aunque hay q preocuparse por implementar cada funcionalidad).
5. (y acabo ya!!) WorkData es aquella clase que encapsula los datos de la petición y de la respuesta. Además encapsula la sesión y el manejor de cookies. (este último está aún por implementar )
Y creo que ya paro! menudo ladrillazo, lo siento señores

vitxete.

[Webstudio]

Bueno, me parece todo impecable realmente, una buena implementación de un Controlador, Acciones y Vistas. Sería muy interesante pegarle una revisada a los ActionManager, ViewManager y TemplateManager para ver como implementan la lógica.

De todas maneras, te comento que después de haber estado en el Post de Sitepoint discutiendo de este tema, llegué a una nueva implementación que voy a publicar esta semana o la siguiente, ya esperando que sea funcional minimamente, hasta que le implemente el FilterChain y esas cosas.

Me gustó particularmente el uso de TemplateManager para devolver una SuperVista que incluye la vista de la acción, eso mismo tenía planeado hacer.

Espero tener el código para esta semana, o durante el fin de semana, y ya creo que lo pondré como un .zip porque ponerlo en un post será mucho.

Saludos.

[vitxo]

Bueno, los Managers son muy parecidos:
- implementan un singleton
- tienen el método getX que devuelve un objeto construido del tipo X (que previamente está almacenado en un array de objetos tipo X, ya sean acciones, vistas o plantillas)
Yo espero tenerlo funcionando en unos días, porque me corre bastante prisa y estoy reescribiendo el motor que hice el año pasado, esta vez quiero hacerlo de forma OO muy rigurosa.
Aunque dejaré el tema de Iteradores y filtros para más adelante.
También se puede aprovecharl patrón observer para relacionar acciones: que unas escuchen a otras.
Juraría que lo había escrito ya, pero con las vistas se puede diferenciar: (interfaz para este caso son clases abstractas)
- interfaz: FullScreenView que contenga su propio "layout", ignorando el del controlador.
- interfaz: Portlet o Boxlet no sé que implemente cierta lógica del negocio para mostrarla en "cajitas" (como lo de: últimos mensajes en el foro X),o bien que escuche a ciertas acciones (post, newthread) y genere la salida en consecuencia.

Por cierto, como sigamos así tendremos pa escribir un libraco

nos leemos.

[vitxo]

Oye, entonces el tema de la vista podría quedar así: todas las acciones tienen en común que devuelven un objeto de la vista con el mismo nombre de la acción.
Así que en AbstractAction.process():

Código PHP:

  function process( &$data ){ 
  $views =& ViewManager::getInstance(); 
  return $views->getView( $this->name ); 
  //ó en vez de name $data -> getParameter('action'); 
}  
   

A lo que iba, en una acción particular digamos: HelloWorldAction su método process() debería invocar a AbstractAction::process() al final para devolver la vista no? Porque sobreescribir no implica que se llame al método padre automáticamente, no?

De tal forma que se lo pasamos a la interfaz Template, a través del método expose.

Código PHP:

  $controllerView -> expose( 'view', $view ); 
//esta linea a continuación puede ser discutible 
$controllerView -> expose( 'data', $data );  
   

correspodiéndose eso con una plantilla PHP:

Código PHP:

 <html> 
<body> 
<?php echo $view -> render( $data ) ?> 
</body> 
</html>  

No lo he terminado de implementar, pero bueno, puede ser la solución. Para PHPMarker tendría que implementar una etiqueta especial para la ocasión, como un

Código:

<include-view name="nombre de la vista"/>

Bueno bueno, me voy a comer que ya son horas

[vitxo]

Más sobre factorías:
Dije antes que cada factoría almacena los objetos que fabrica en un array que tiene como atributo de clase.
En concreto me estoy pegando ahora con el ActionManager, el encargado de fabricar acciones.
Tal y como lo tengo ahora, en el constructor creo una instancia de cada acción que tenga implementada (ahora mismo sólo un HelloWorldAction), le añado los parámetos que necesitan a través del addProperty (las acciones necesitan su propio nombre y parámetros adicionales que necesites, y las vistas la plantilla además de su propio nombre) y la añado al array las mantiene.

Esta tarea la voy a tener que repetir para cada acción y vista nueva que implemente. No habría alguna manera de hacerlo automático? Se me ocurren varias formas:
A :
1. listar los archivos que haya en el directorio que contiene el código fuente de las acciones
2. utilizar el nombre para instanciar el objeto
de la forma:

Código PHP:

    $filename = 'HelloWorldAction.class.php';   
  $classname = //coger de la variable filename sólo 'HelloWorldAction'. 
  $action =& new $classname.'()'; 
  $action -> addProperty( 'name', 'helloworld'); 
  $this->actions[ $action->getName() ] =& $action;  
   

B:
1. usar archivos de configuración con nombres de acciones, nombres de las clases, propiedades de cada acción (texto plano, XML o lo que convenga), pero tampoco es plan de interpretar/leer la configuración de los archivos a cada petición. Para evitar eso se podría guardar una copia "traducida" a PHP de la configuración, y como mucho comparar los checksums de los archivos de config. para ver cuándo cambian y actualizar la configuración. (eso es lo que hago en PHPMarker, así es como almaceno una copia en caché de la plantilla actual)-
Pero joer, se torna PELUDO el asunto ehh?

2. usar archivos de configuración en PHP. --> no me termina de convencer, pero a lo mejor es la única opción viable.

nos leemos.

[vitxo]

Importante esta dirección referencia para implementar un procesador/validador de formularios Orientado a objetos. Muy interesante, le estoy dado cañita ahora.

Me he equivocado impemlementando los singleton porque no se mantienen. Porque no debería especificar esto en cada Vista:

Código PHP:

  $manager -> setTemplateDirectory('presentation/');  
   

Porque ya lo he hecho antes en el contolador (en el constructor de hecho).

un saludete.

[vitxo]

Por cierto, en http://linuv.uv.es/2004 está funcionando la web con una acción y una vista :)

[vitxo]

hola de nuevo!

He estado pensando.
Para la web que estoy haciendo se distiguen "tres webs diferentes", es decir, que mi aplicación tiene tres vistas diferentes. Cada una usa una plantilla diferente par el "layout" o maquetación de la página.

Entonces implementé las tres vistas que heredan de la interfaz FullscreenView. No he desarrollado bien la idea y me he peleado un poco con las acciones que se ejecutan "dentro" de cada vista, vamos un lío de narices.

Alternativas que he pensado pero necesito puntos de vistas de terceros :
1. Que el controlador tenga su propio nombre y plantilla bien definidos: un atributo de clase var $nombre y $plantilla.

Entonces al detectar que una vista es de tipo FullscreenView (porque hereda de ella tipo, atributos y métodos), que obtenga la ruta de la plantilla y la use en vez de la plantilla del controlador. ($view -> getTemplatePath() en vez de $this->getTemplatePath()). FullscreenView pasaría ser una clase abstracta.

Pero, tanto lío de herencia para luego eso? no sé

2. Como todos los objetos se destruyen y se crean a cada nueva petición, estaré obligado a persistir el FullscreenView para mantener ese layout. Pero si me pongo a meter parámetros en la URL teng "miedo" de caer otra vez en el lío.

Así que si creo tres objetos controladores en el index.php al que llamamos desde el navegador, uno para cada vista de cada evento que quiero se me solucionan muchos problemas (me olvido ya del singleton del controlador), además que reusaría las acciones hasta tres veces (eso tiene buena pinta??).
Igualmente tengo que elegir siempre un controlador con un parámetro en la URL de la siguiente manera:

Código:

index.php?controller=iparty

Para ejecutar la accion login del controlador de la iParty (el nombre del evento):

Código:

index.php?controller=iparty&action=login

Ahora que caigo, es un enfoque parecido al del FullscreenView.

leyéndonos que es gerundio.

[Webstudio]

Hola Vitxo, veo que te hiciste un lio peliagudo con el tema Vistas, Acciones, Controllers y "SuperVistas"...
Mira, es algo que tendría que comenzar a responderte desde el primer post de esta pagina, lamentablemente ahora ando con poco tiempo porque tengo que hacer una entrega el Miércoles, pero luego veré de que discutamos este tema un poco mejor. Solo para tenerte informado de que no he dejado de leer este post y que estoy interesado en ver la implementación completa que tienes del MVC ( sobre todo lo de las vistas )-.

Más luego.

[vitxo]

Sí, la verdad que la armé un poco pero parece que ahroa todo funciona como quería. Pero seguro que hay una forma más lógica de hacerlo, por lo pronto no me interesa
Ya sabes, las prisas son muy mala compañía y yo tengo mucha (la web deberia estar acabada HOY )

seguimos leyéndonos.

[Webstudio]

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.

[biblio]

Espero tener el código para esta semana, o durante el fin de semana, y ya creo que lo pondré como un .zip porque ponerlo en un post será mucho

Espero que no te olvides poner el zip: me he paseado por todos los post que hay aca y en sitepoint, me he quedado corto en algunas cosas.

Saludos

[Webstudio]

Mensaje Original por biblio


Espero que no te olvides poner el zip: me he paseado por todos los post que hay aca y en sitepoint, me he quedado corto en algunas cosas.

Saludos

Si no lo puse aún es porque después de utilizar el Framework en un proyecto que estoy realizando, no quedo conforme con ciertos aspectos del mismo, que me gustaria cambiar para que no quede muy desprolijo. Lo mismo me sucede con que tengo una nueva implementación del Patrón Controllador, mucho más flexible, en mente y quiero desarrollarla para este Framework.

[vitxo]

Llevo unas semanas sin postear por aquí, sigo leyendo pero ahora estoy liadísimo con las Jornadas de Software Libre
Todavía tengo q pulir mi framework y hacerlo un poco más "general", porque por ahora he implementado sólo una aplicación para gestionar el proceso de inscripción y pago y algo parecido a un sistema de usuarios para controlar a los adminsitradores.

Por cierto, menos mal q estoy subscrito a este hilo porque debe estar en las páginas de la prehistoria de estos foros.

nos leemos!