Write haof XML files: Gustavo Pardo
(
dataneu@gmail.com)
Fecha: lun 23 ene 2006 - 18:58:50 CET
hola,
me parecen muy positivos los comentarios de cada uno.
les cuento que soy de los que he aprendido algunas cosas (MVC
x ejemplo) a los
palos, como alguien comentó por allí. no tengo
muchos estudios teóricos sobre
programación (sólo un año), pero
comencé a programar por hobby a los 19 años
(ya hace 16 :) pueden sacar cuentas...) con dBaseIII+
(qué antiguedad!!!!!),
luego Clipper/Visual FoxPro y desde hace un par de
años LAMP a full.
creo que para los que están como yo (aprendiendo a los
palos :) ) un buen
framework facilita mucho las cosas para realizar una
aplicación robusta y
sobre todo, escalable.
a todos los que han contribuido a este hilo: Gracias!
-- Gustavo Pardo http://drupaleros.com.ar/ El Lun 23 Ene 2006 10:41, carlos Medina escribió: > Hola Hari, > > reconozco que tu posicion esta bien fundamentada. Una de las cosas mas > dificiles para mi fue el imaginarme de donde viene un Request y a donde > va mi respuesta del servidor. Te lo cuento porque yo pensaba que me > ahorraba mas tiempo implementando yo todas las clases que usaria en un > proyecto determinado sin tener que usar un framework. Ahora que he > comenzado este proyecto grande he visto que es necesario. > > Os cuento que el proyecto no es nada del otro mundo. Una pagina con un > index.php un par de clases y una base de datos. Asi comenzó todo y hasta > el ano pasado muy bien. Luego comenzaron los problemas (digo problemas > por decir) > La integracion de los Clients fue lo primero que tuvimos que hacer. > Clients en IRIX,AIX,Windows. Nos tomamos un tiempo y vimos que era lo > mas logico que las queries proveniente de las maquinas via port 80 > (geroutet sobre 8080) en direccion al servidor se podian implementar en > los derivados de unix a traves de un PERL llamando un socket con salida > hacia el puerto 80 y enviandole la informacion via POST a un script PHP. > Pues bien la pregunta era: donde colocar este script? - la respuesta es > muy logica. En el Controller. > Nuestra aplicacion responde pues a diferentes tipos de queries que se > pueden hacer desde el browser o desde una maquina via Socket. Asi le > queda al Controller decidir, que va a responder (nada solo un log). > > En este ejemplo (solo pequeno) puedes ver como se puede aplicar el MVC. > Seguro que el MVC no es la respuesta a todos los problemas sino solo una > alternativa mas en toda la marana de posibilidades que se tienen a la > mano. Creo que las personas que dicen (solo usando framework y usando > MVC) estan tan equivocados como los que dicen (nunca usando Framewokrs o > MVC). No me entiendas mal. Pienso que el uso de un Framework depende > mucho de lo que se vaya a hacer. Asi en cierta forma estoy de acuerdo > contigo > > Saludos > > Carlos > > Hari Seldon wrote: > > Bueno, yo personalmente no he trabajado (de momento) con ningún > > framework en PHP.. Y no lo he hecho por mis propias razones. > > > > La verdad es que programar dentro de un framework, te obliga a > > programar como esté hecho ese framework.. Quieras o no. > > > > Por ejemplo, Prado sigue el paradigma MVC (me resisto a llamarlo > > patrón de diseño... Es un patrón arquitectónico en tal caso más que un > > patrón de diseño); pues automáticamente tu aplicación deberá de seguir > > este paradigma, y ello a veces no es "tan óptimo". > > > > ¿Por qué no es tan óptimo?; bueno, veamos, expliquemos rápidamente > > qué es un MVC (para quién no lo conozca): > > > > MVC son las siglas de Model-View-Controller. Normalmente en > > cualquier aplicación OOP, se tienen varias clases que se comunican entre > > sí; MVC intenta "estandarizar" esta comunicación. ¿Cómo lo hace? Pues > > bien, divide la aplicación en un controlador (Controller), en el Modelo > > (Model), y en Vistas (View); el controlador recibe las peticiones del > > usuario, y con ellas decide que clase o clases instancia del modelo, esto > > es, "refresca" el Modelo (el Modelo recibe las peticiones que le > > corresponden); la parte del Modelo es la encargada de llevar la lógica de > > la aplicación, esto es, conexión con base de datos, gestión de la > > información, etc etc etc (y se refresca a si mismo en función de las > > peticiones del Controller lógicamente, además de refrescar/mostrar las > > Vistas). Por tanto, es la parte > > "inteligente" de nuestra aplicación. Por último, las Vistas son lo que su > > nombre indica... Vistas de "salida" -normalmente son de salida...-, como > > resultado a las peticiones del usuario. Vamos, un listado de una > > búsqueda, un formulario de edición de datos, ... Lo que se os ocurra. > > > > La explicación es "chapucera", pero creo que la idea de MVC queda > > más o menos clara. > > > > El caso es que este paradigma viene de SmallTalk y del mundo Java; y > > ahí funciona francamente bien, por cómo es la arquitectura de J2SE/J2EE; > > y para una aplicación cliente/servidor tradicional, también funciona > > francamente bien. Es una forma de programar elegante, muy bien > > encapsulada, y muy extensible (daros cuenta que integrar vistas > > diferentes es muy sencillo... Prácticamente no habrás de tocar el > > controlador para nada, y el modelo tampoco, sino implementar tus vistas > > nuevas; si implementas nuevas funcionalides, por fuerza has de tocar el > > modelo, pero el controlador no sufriría más que los cambios necesarios > > para redirigir las peticiones de las nuevas funcionalidades. Lógicamente > > habría que desarrollara además las vistas que se necesiten para las > > nuevas funcionalidades. Vamos, que hasta aquí muy bonito. > > Pero una aplicación web en PHP, funciona un poco "diferente" a como > > funcionan otro tipo de aplicaciones; veamos, un caso típico son las > > aplicaciones que utilizan un index.php en el root del web, para después > > realizar las operaciones que se necesiten. Por ejemplo: > > Midominio.com?do=editUser&idUser=1 > > > > Podría ser una edición del usuario con la id 1 > > > > Pero lógicamente, esto llamaría a index.php... > > > > El número de "acciones" que se pueden realizar en una aplicación web > > compleja, son _bastantes_ (pensemos, simplemente, en listar, editar, > > insertar, eliminar, o sea, 4 acciones diferentes, y multiplequémoslo por > > el número de "información" que tengamos -usuarios, noticias, artículos, > > imágenes, galerías.....) En definitiva, que salen bastantes acciones... > > > > Y todas y cada una de ellas pasan por el index.php... Lo cuál, por > > fuerza, "cargan" este archivo. > > > > En una arquitectura Java, existe la ventaja de que el Controller > > normalmente suele ser un Servlet que se encuentra instanciado en todo > > momento, vamos, se instancia al arrancar el servidor web; en cuánto a una > > aplicación cliente/servidor, sucede lo mismo, la instancia del Controller > > va a iniciarse y morir con la aplicación; sin embargo, en una aplicación > > en PHP esto NO ES ASÍ. Cada vez que llamemos a index.php, este se va a > > instanciar en memoria, y vamos a forzar al Zend Engine a interpretarlo y > > ejecutarlo; lógicamente, la parte de ejecución es común a cualquier caso; > > pero no lo es la parte de la interpretación. Existen técnicas para > > cachear el fichero "interpretado", pero suelen ser complejas... Con lo > > cuál, a mi modo de ver, volvemos al principio. > > > > Suponer una aplicación con unas 100 acciones diferentes, no es para > > nada descabellado; y por cada una de las acciones, siempre siempre > > estaríamos instanciando nuestro mismo Controller; y para cada acción, le > > obligaríamos a hacer una "búsqueda" entre sus 100 acciones para realizar > > lo oportuno; vamos, normalmente el index.php de una aplicación así > > enfocada es un enooooooooorme switch case ;) > > > > La ventaja evidente es que tengo centralizado la gestión de > > peticiones; la desventaja, para mi, es que se vuelve menos óptimo de > > forma exponencial a medida que aumente el número de > > acciones/funcionalidades diferentes en nuestra aplicación. > > > > Yo, particularmente, prefiero un enfoque más "segmentado", y lo que > > suelo hacer es definir un "controller" por cada LEIE (listar, editar, > > insertar, eliminar) que necesito en mi aplicación; así no tengo un > > Controlador tan "grande" que instanciar, ni le hago trabajar tanto. Creo > > que hay por ahí algún documento por la red de este enfoque, vamos, no me > > lo he inventado yo... Pero me parece un enfoque muy interesante. > > > > En otros thread de la lista, manteníamos este mismo "debate" con > > Pablo Siciliano, y algún otro; Pablo comentaba que él adopta una > > estrategia de MV (modelo-vista) y prescinde muchas veces del Controller; > > es lógico el planteamiento, porque muchas veces el Controller es una > > vista.. El caso más claro es un formulario de edición que hace submit > > sobre si mismo (para indicar al usuario sobre el mismo formulario los > > errores; si, ya se que con un include se puede solucionar también, pero > > bueno, repito, son enfoques diferentes). > > > > Volviendo al tema del framework, como comentaba, el utilizar un > > framework determinado, me obliga a trabajar de una forma determinada, > > leerme documentación acerca de cómo funciona el framework, y quizás no > > ahorrar tanto tiempo como yo suponía.. O bien que la aplicación la esté > > programando de una forma que a mi no me convence al 100 %; lógicamente, > > si tengo en mente realizar varias aplicaciones con un mismo framework > > durante un tiempo, digamos, por ejemplo, un año (o bien la misma....), > > pues puede compensarme realizar un framework; pero lo habitual en una > > aplicación en entorno web es que tenga un ciclo de desarrollo de máximo > > unos 8-9 meses, más de ese tiempo... Malo, es que algo no va del todo > > bien (lo habitual, al menos así lo entiendo yo, son 3-6 meses para una > > aplicación de tamaño medio-grande; con el aumento de complejidad, han de > > aumentarse los recursos > > -desarrolladores-, pero no el tiempo de desarrollo, pues a más tiempo de > > desarrollo, más "obsoleta" va a ser nuestra aplicación, y más tardamos en > > cubrir las necesidades de nuestro cliente, con lo cuál probablemente este > > tenga además de las necesidades iniciales, otras nuevas... Le estaremos > > dando un producto "viejo", en mi opinión). > > > > Bueno, vaya rollo que os he soltado... Es que hoy me he levantado > > "filosófico", y me he puesto a escribir.... > > > > Pero creo que los puntos de vista que expongo, son para tener en > > cuenta, y aunque quizás esten equivocados, creo que son interesantes... Y > > motivo de un interesante debate si todos quereis participar en él ;) > > > > Un saludo a todos :) > > > >>-----Mensaje original----- > >>De: carlos Medina [mailto:info@simply-networks.de] > >>Enviado el: lunes, 23 de enero de 2006 9:53 > >>Para: php-es@lists.php.net > >>Asunto: [PHP-ES] Re: Framework PHP > >> > >>Hola Lista, > >> > >>Como dijo Gustavo Prado, un framework es un marco de trabajo > >>en el cual > >>ya se encuentran muchas clases "precocinadas" para que el > >>programador de > >>sitios grandes tenga un instrumento medio standard para su > >>aplicacion(me > >>refiero a aplicaciones en la cual trabajen varios programadores). > >>En realidad la mayoria de los trabajos en PHP son muy "sencillos": > >>formularios, foros, rutina mail y otros. La mayoria de los > >>casos cuando > >>se comienza un proyecto, nunca se sabe bien, que tan grande > >>va a llegar > >>a ser. En estos casos se utiliza un framework para que el desarrollo > >>tenga ya desde su base una estructura en la cual el programador > >>(sobretodo el nuevo) pueda "entrar" al desarrollo con mas > >>facilidad y se > >>tenga una base de las clases mas usadas. > >> > >>En un proyecto de gran alcance en el cual trabajo acualmente (combina > >>PHP, Java, JavaScript,PERL, C++ y ShellScript de integracion > >>en sistemas > >>linux, AIX, IRIX, Windows y MAC X) utilizamos el framework > >>seagull, que > >>segun el cliente es uno de los mas potentes pero al mismo tiempo mas > >>entendibles. > >> > >>Cuando hay que desarrollar paginas nuevas o nuevos features > >>se tienen a > >>la mano una serie de herramientas como la conexion al DB > >>(independientemente de si es DB2, MySQL u ORACLE) con las > >>cuales manejo > >>los query sin tener que escribir el consabido "SELECT * FROM"... > >> > >>A mi me gusta > >> > >>Saludos > >> > >>Carlos > >> > >>Daniel Naranjo wrote: > >>>Hola, disculpa mi ignorancia, pero para que sirve un > >> > >>framework para php? actualmente desarrollo en php 4, pero no > >>entiendo muy bien el uso de un framework? > >> > >>>Salu2 > >>>Daniel > >> > >>-- > >>PHP Spanish Localization Talk Mailing List (http://www.php.net/) > >>To unsubscribe, visit: http://www.php.net/unsub.php > >> > >> > >>__________ Información de NOD32 1.1373 (20060120) __________ > >> > >>Este mensaje ha sido analizado con NOD32 antivirus system > >>http://www.nod32.com -- PHP Spanish Localization Talk Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Este archivo fue generado por hypermail 2.1.7 : sáb 18 mar 2006 - 18:23:29 CET