FAQ
Debo desarrollar un sistema grande en PHP, actualmente e desarrollado
cosas pequeñas y lo he hecho utilizando solamente templatepower y
ADODb.
Alquien conoce algun framework estable y recomendale para un
desarrollo de soft de gran dimension?
Algun comentario sobre PRADO ? Es veloz funcionando con grandes cargas?

Saludos
Cristian

Search Discussions

  • Fernando Gutierrez at Jan 20, 2006 at 5:52 pm
    symfony http://www.symfony-project.com/
    cake http://cakephp.org/
    seagull http://seagull.phpkitchen.com/

    Estos proyectos estables... yo he estado probando symfony y tiene buena
    pinta ademas esta muy documentado ( tiene un tutorial que duro 24 dias sobre
    un proyecto bastante grande )
    De los otros dos he leido cosas bastante buenas pero no los he probado
    On 1/20/06, Cristian Bullokles wrote:

    Debo desarrollar un sistema grande en PHP, actualmente e desarrollado
    cosas pequeñas y lo he hecho utilizando solamente templatepower y
    ADODb.
    Alquien conoce algun framework estable y recomendale para un
    desarrollo de soft de gran dimension?
    Algun comentario sobre PRADO ? Es veloz funcionando con grandes cargas?

    Saludos
    Cristian

    --
    PHP Spanish Localization Talk Mailing List (http://www.php.net/)
    To unsubscribe, visit: http://www.php.net/unsub.php

    --
    -- Fernando Gutierrez Perez --
    gmeileando un poco :)
  • Pvergara at Jan 23, 2006 at 8:31 am

    El Viernes, 20 de Enero de 2006 18:52, Fernando Gutierrez escribió:
    symfony http://www.symfony-project.com/
    cake http://cakephp.org/
    Dicen que es el Ruby on rails del php... pero...Versión 0.10.7.1856 RC3...
    ¿estable?... quizás... pero muuuy poquito desarrollado
    La versión estable de éste otro es la 0.4.7 [2005-11-11] ( <=Parece que hace
    tiempo que no se pasa a estable... siii se que hay otra inestable de
    diciembre... pero no es plan utilizar esa rama en proyectos serios)
    Estos proyectos estables... yo he estado probando symfony y tiene buena
    pinta ademas esta muy documentado ( tiene un tutorial que duro 24 dias
    sobre un proyecto bastante grande )
    Vaya pues symfony no la conozco..

    Después de ver varios frameworks en la empresa en la que yo trabajo, el que
    estuvimos mas a punto de utilizar fué prado, por su increible madurez y su
    trabajo realmente bueno y completo.

    Ahora, si lo único que se busca es la persistencia, un framework como estos
    puede venir muy grande porque no es sólo a eso a lo que se ocupan (es mas una
    búsqueda de la aplicación de todo o parte del patrón MVC).

    Yo siempre he tenido mis dudas sobre como obtener información de varias tablas
    a la vez con frameworks de persistencia de objetos... que es lo único que
    siempre me ha hecho que al final me haga yo las cosas a mano.

    Saludos.



    --
    ----
    Pablo C. Vergara Castro.
    Departamento de informática.
    TQR-Software
    Tlfno.: (+34) 986 39 31 49
    Fax: (+34) 986 31 25 96


    La información transmitida va dirigida únicamente a la persona o entidad
    que se muestra como destinatario y puede contener datos confidenciales o
    privilegiados. Toda revisión, retransmisión, diseminación u otro uso o
    acción al respecto por parte de personas o entidades distintas al
    destinatario está prohibida. Si recibe esto por error, por favor
    contacte con la persona que figura como remitente y elimine el material
    de cualquier ordenador.


    The information transmitted is intended only for the person or entity to
    which it is addressed and may contain confidential and/or privileged
    material. Any review, retransmission, dissemination or other use of, or
    taking of any action in reliance upon, this information by persons or
    entities other than the intended recipient is prohibited. If you
    received this in error, please contact the sender and delete the
    material from any Computer.
  • Gustavo Pardo at Jan 21, 2006 at 4:12 pm

    El Vie 20 Ene 2006 14:23, Cristian Bullokles escribió:
    Debo desarrollar un sistema grande en PHP, actualmente e desarrollado
    cosas pequeñas y lo he hecho utilizando solamente templatepower y
    ADODb.
    Alquien conoce algun framework estable y recomendale para un
    desarrollo de soft de gran dimension?
    Algun comentario sobre PRADO ? Es veloz funcionando con grandes cargas?

    Saludos
    Cristian
    "recomendable" no, yo también estoy buscando, pero para investigar aquí hay
    varios: http://www.phpwact.org/php/mvc_frameworks
  • Daniel Naranjo at Jan 21, 2006 at 5:35 pm
    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
  • Gustavo Pardo at Jan 21, 2006 at 5:58 pm

    El Sáb 21 Ene 2006 14:35, Daniel Naranjo escribió:
    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
    jeje, yo me acabo de enterar, hasta el momento me parece que como su nombre
    indica, es un marco de trabajo adecuado y ordenado para comenzar con una
    aplicación/sitio medianamente importante.

    ya incluye algunas clases/funciones de uso muy común, y algunas de las
    características más salientes (para mí x lo menos) es que trabajan con MVC,
    PHP5 y AJAX por ejemplo.

    a la hora de comenzar un laburo, si ya tenés esto pre-cocinado, podés
    enfocarte con más detalles en los aspectos más críticos de tu laburo.

    supongo que gente con más experiencia pueda hacer comentario un poco más
    acertados.

    saludos.
  • JESE at Jan 22, 2006 at 7:27 pm
    Hola:

    Yo tampoco lo veo claro... ¿un FrameWork viene a ser como un IDE
    (Integrated Development Environment)?

    "Gustavo Pardo" <dataneu@gmail.com> escribió en el mensaje
    news:200601211503.35696.dataneu@gmail.com...
    El Sáb 21 Ene 2006 14:35, Daniel Naranjo escribió:
    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
    jeje, yo me acabo de enterar, hasta el momento me parece que como su nombre
    indica, es un marco de trabajo adecuado y ordenado para comenzar con una
    aplicación/sitio medianamente importante.

    ya incluye algunas clases/funciones de uso muy común, y algunas de las
    características más salientes (para mí x lo menos) es que trabajan con MVC,
    PHP5 y AJAX por ejemplo.

    a la hora de comenzar un laburo, si ya tenés esto pre-cocinado, podés
    enfocarte con más detalles en los aspectos más críticos de tu laburo.

    supongo que gente con más experiencia pueda hacer comentario un poco más
    acertados.

    saludos.
  • carlos Medina at Jan 23, 2006 at 8:52 am
    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
  • Hari Seldon at Jan 23, 2006 at 10:42 am
    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
    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
  • Vladimir Hernandez at Jan 23, 2006 at 11:31 am
    Empezaré por decir que era hasta muy recientemente ignorante de este tipo de
    cuestiones. Estuve codificando en un editor de texto hasta hace unos meses,
    cuando pasé a un IDE. Siendo un programador que empezó con BASIC desde que
    tenía número de línea mucha de la programación moderna me ha tenido que
    entrar a la fuerza.

    Veo desde mi limitada perspectiva que al menos para aplicaciones Web
    con PHP no
    puedo sino coincidir con Hari. Mis razones son menos técnicas, más bien en el
    sentido que menciona él al final en cuanto al tiempo de desarrollo. Debido a
    que nuestra área (Web) está en muy frecuente cambio, fuera de lo elemental
    (que tuve que aprender por el camino duro) que es separar la lógica de la
    presentación, no me puedo imaginar (insisto en que mi perspectiva es limitada)
    el porqué separar en más que esas dos capas cuando todo lo que hacemos
    necesitará casi seguramente ser revisado y muy posiblemente re-hecho en menos
    de un año, esto por la necesidad de incluír nuevas capacidades a la
    aplicación (léase ajax), o por el cambio tecnológico de nuestra plataforma.

    Me atrevo a pensar -por los postings en esta lista- que la mayoría utilizamos
    LAMP/WAMP, que es (fuera de la W) software libre, en esencia en permanente
    cambio y desarrollo. Esto cambia la forma en que se harán las aplicaciones en
    el mediano plazo. Por ejemplo, cuando la mayoría pasemos a los "cincos" (PHP
    5/MySQL 5) con bastante probabilidad haremos uso de procedimientos almacenados
    y triggers, dejando mucho de lo que tengamos hecho hasta el momento obsoleto.
    Tal vez a este punto un framework comience a tener sentido, pues una
    gran parte
    de la lógica puede quedar en la base de datos, pero al momento me parece una
    inversión de tiempo en algo que preveo tendrá que ser sustituído muy pronto.

    E insisto, es mi muy limitado punto de vista, declarándome el menos capacitado
    tal vez para opinar al respecto. Igual y lo que dije no va con el tema,
    en cuyo
    caso pido una disculpa anticipada. Sólo que al revisar los links sobre los
    Frameworks existentes me puse a calcular lo que debía desviar de mi tiempo de
    desarrollo en aprender algo nuevo y hasta el momento para mi innecesario.

    --
    Vladimir Hernández
    http://linuxbaja.org/
    Linux user #374079

    Quoting Hari Seldon <hari.seldon@telefonica.net>:
    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
    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
  • Cristian Bullokles at Jan 23, 2006 at 12:46 pm
    Particularmente como comentaba he trabajado de esta forma, con
    templatepower para separar la logica de lo que es la presentacion de
    los datos.
    Creo que la idea de elegir un buen framework va con la idea de que
    dicho framework ayude a crecer en la aplicacion a medida que avanzan
    las tecnologias.
    Deberia estudiar con mayor detenimiento pero creo que symphony cumple
    con alguna de estas caracteristicas deseables.


    On 1/23/06, Vladimir Hernandez wrote:
    Empezaré por decir que era hasta muy recientemente ignorante de este tipo de
    cuestiones. Estuve codificando en un editor de texto hasta hace unos meses,
    cuando pasé a un IDE. Siendo un programador que empezó con BASIC desde que
    tenía número de línea mucha de la programación moderna me ha tenido que
    entrar a la fuerza.

    Veo desde mi limitada perspectiva que al menos para aplicaciones Web
    con PHP no
    puedo sino coincidir con Hari. Mis razones son menos técnicas, más bien en el
    sentido que menciona él al final en cuanto al tiempo de desarrollo. Debido a
    que nuestra área (Web) está en muy frecuente cambio, fuera de lo elemental
    (que tuve que aprender por el camino duro) que es separar la lógica de la
    presentación, no me puedo imaginar (insisto en que mi perspectiva es limitada)
    el porqué separar en más que esas dos capas cuando todo lo que hacemos
    necesitará casi seguramente ser revisado y muy posiblemente re-hecho en menos
    de un año, esto por la necesidad de incluír nuevas capacidades a la
    aplicación (léase ajax), o por el cambio tecnológico de nuestra plataforma.

    Me atrevo a pensar -por los postings en esta lista- que la mayoría utilizamos
    LAMP/WAMP, que es (fuera de la W) software libre, en esencia en permanente
    cambio y desarrollo. Esto cambia la forma en que se harán las aplicaciones en
    el mediano plazo. Por ejemplo, cuando la mayoría pasemos a los "cincos" (PHP
    5/MySQL 5) con bastante probabilidad haremos uso de procedimientos almacenados
    y triggers, dejando mucho de lo que tengamos hecho hasta el momento obsoleto.
    Tal vez a este punto un framework comience a tener sentido, pues una
    gran parte
    de la lógica puede quedar en la base de datos, pero al momento me parece una
    inversión de tiempo en algo que preveo tendrá que ser sustituído muy pronto.

    E insisto, es mi muy limitado punto de vista, declarándome el menos capacitado
    tal vez para opinar al respecto. Igual y lo que dije no va con el tema,
    en cuyo
    caso pido una disculpa anticipada. Sólo que al revisar los links sobre los
    Frameworks existentes me puse a calcular lo que debía desviar de mi tiempo de
    desarrollo en aprender algo nuevo y hasta el momento para mi innecesario.

    --
    Vladimir Hernández
    http://linuxbaja.org/
    Linux user #374079

    Quoting Hari Seldon <hari.seldon@telefonica.net>:
    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
    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
    --
    PHP Spanish Localization Talk Mailing List (http://www.php.net/)
    To unsubscribe, visit: http://www.php.net/unsub.php
  • carlos Medina at Jan 23, 2006 at 1:42 pm
    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
    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
  • Hari Seldon at Jan 23, 2006 at 2:53 pm
    Jejeje completamente de acuerdo Carlos.

    Yo no digo "no uses MVC"... Digo, úsalo, pero sabiendo cuáles son
    sus puntos débiles y sus puntos fuertes ;)

    Sobre el uso o no de un framework, comento el tema de MVC porque los
    que habeis puesto usan ese paradigma. Y ojo, me parece que es lo que debe de
    hacer un framework; ser lo más generalista y estándar que pueda; y a día de
    hoy el paradigma MVC es el más extendido, y el que más se usa.

    Pero también usamos (bueno yo uso como escritorio...) Windows, y no
    es lo óptimo o lo mejor.. Pero lo usamos porque es más cómodo (yo al menos,
    para ciertas cosas, me es más cómodo que linux, que también tengo, pero como
    server).

    Y aquí es dónde entra la labor del verdadero y real
    ingeniero/analista; ¿cuándo sacrificar rendimiento contra tiempo de
    desarrollo?; está claro que una aplicación hecha totalmente a medida, sin
    nada de código reutilizable, etc etc etc, será siempre más óptima que otra
    en la cuál estamos reutilizando código (el ejemplo claro lo tenemos con PEAR
    DB, que a pesar de que es un package -para mi forma de ver al menos- genial,
    que hace todo lo que debería de hacer un capa de abstracción de base de
    datos, sacrifica en rendimiento, pues nunca va a ser tan rápido como usar
    las funciones nativas para uso de mysql -o de la base de datos que
    utilizes-). Muchas veces resulta más viable sacrificar rendimiento por
    velocidad en desarrollo, y otras veces, no.

    La frase "solución de compromiso" es todo un lema en el buen
    ingeniero... Y lo que le hace bueno, es que llegue al compromiso ideal ;)

    Pero bueno, volviendo al tema, yo no digo "frameworks no", ni "MVC
    no".. Sino, hay que usarlos, cuándo compense hacerlo (en el caso de los
    frameworks), y en el caso de MVC, sabiendo lo que estamos haciendo.

    Ojo... Es mi opinión, por supuesto :)

    Un saludo a todos (y gracias por las respuestas que siempre son muy
    productivas)
    -----Mensaje original-----
    De: carlos Medina
    Enviado el: lunes, 23 de enero de 2006 14:42
    Para: php-es@lists.php.net
    Asunto: Re: [PHP-ES] Re: Framework PHP

    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
    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


    __________ Información de NOD32 1.1373 (20060120) __________

    Este mensaje ha sido analizado con NOD32 antivirus system
    http://www.nod32.com
  • carlos Medina at Jan 23, 2006 at 3:15 pm
    Precisamente Hari,
    creo que estamos de acuerdo en todos estos puntos. Mi pregunta (y se que
    con ello casi me OT) es la siguiente:

    Hasta que punto se puede "sacrificar" rendimiento por velocidad de
    desarrollo?. Lo mas impresionante que he visto en velocidad de
    desarrollo y rendimiento casi maximizados ha sido utilizando OMNIS RAD
    (de la casa Raining Data). Tengo la suerte de conocer la casa proveedora
    aqui en alemania y he quedado impresionado de la velocidad con que se
    programa en Omnis y la velocidad de respuesta asi como la confiabilidad
    del sistema. (ojo tanto web como client).

    Mis esperanzas es ver (o crear) una framework en PHP que no limite el
    rendimiento y que sea lo bastante flexible como para que cualquiera
    pueda trabajar con el comodamente y rapido.
    Quizas se tenga que invertir tiempo en disenar una IDE especifica para
    PHP que perfeccione estas cosas. Quizás TRUStudio o eclipse (son los que
    uso) :-)

    Bueno ahora si estoy OT y por eso cierro

    Saludos

    Carlos

    Hari Seldon wrote:
    Jejeje completamente de acuerdo Carlos.

    Yo no digo "no uses MVC"... Digo, úsalo, pero sabiendo cuáles son
    sus puntos débiles y sus puntos fuertes ;)

    Sobre el uso o no de un framework, comento el tema de MVC porque los
    que habeis puesto usan ese paradigma. Y ojo, me parece que es lo que debe de
    hacer un framework; ser lo más generalista y estándar que pueda; y a día de
    hoy el paradigma MVC es el más extendido, y el que más se usa.

    Pero también usamos (bueno yo uso como escritorio...) Windows, y no
    es lo óptimo o lo mejor.. Pero lo usamos porque es más cómodo (yo al menos,
    para ciertas cosas, me es más cómodo que linux, que también tengo, pero como
    server).

    Y aquí es dónde entra la labor del verdadero y real
    ingeniero/analista; ¿cuándo sacrificar rendimiento contra tiempo de
    desarrollo?; está claro que una aplicación hecha totalmente a medida, sin
    nada de código reutilizable, etc etc etc, será siempre más óptima que otra
    en la cuál estamos reutilizando código (el ejemplo claro lo tenemos con PEAR
    DB, que a pesar de que es un package -para mi forma de ver al menos- genial,
    que hace todo lo que debería de hacer un capa de abstracción de base de
    datos, sacrifica en rendimiento, pues nunca va a ser tan rápido como usar
    las funciones nativas para uso de mysql -o de la base de datos que
    utilizes-). Muchas veces resulta más viable sacrificar rendimiento por
    velocidad en desarrollo, y otras veces, no.

    La frase "solución de compromiso" es todo un lema en el buen
    ingeniero... Y lo que le hace bueno, es que llegue al compromiso ideal ;)

    Pero bueno, volviendo al tema, yo no digo "frameworks no", ni "MVC
    no".. Sino, hay que usarlos, cuándo compense hacerlo (en el caso de los
    frameworks), y en el caso de MVC, sabiendo lo que estamos haciendo.

    Ojo... Es mi opinión, por supuesto :)

    Un saludo a todos (y gracias por las respuestas que siempre son muy
    productivas)

    -----Mensaje original-----
    De: carlos Medina
    Enviado el: lunes, 23 de enero de 2006 14:42
    Para: php-es@lists.php.net
    Asunto: Re: [PHP-ES] Re: Framework PHP

    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
    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


    __________ Información de NOD32 1.1373 (20060120) __________

    Este mensaje ha sido analizado con NOD32 antivirus system
    http://www.nod32.com
  • Hari Seldon at Jan 23, 2006 at 4:12 pm
    Uhmmm lo que comentas es complejo...

    Lo único que conozco que es RAD en webapps, que sea mínimamente
    decente, es Visual Studio .NET, y particularmente, lo _odio_ .... Pero
    bueno, si que es cierto que te ahorras mucho trabajo.

    Para crear un verdadero RAD, habría que crear un montón de
    componentes, tanto a nivel servidor (un framework en PHP), como a nivel
    cliente (librerías javascript, o sea, otro framework en jS; o bien usar
    Flash con alguno de los frameworks existentes... U otros...); y todo eso,
    integrarlo con un IDE.

    El tema es interesante, pero lo veo muy complejo, y tendría que ser
    parte de un proyecto _muy_grande_ para que se llevase a buen puerto.

    En Eclipse por ejemplo, tenemos el caso de VE, que ha tenido que
    esperar hasta la versión 3 de Eclipse para ver la luz, y aún así, no va todo
    lo fino que debiese (al menos cuándo yo lo probé..); si, existían otros, net
    beans -no me gusta mucho..-, y después plataformas de pago como puede ser el
    archiconocido JBuilder.

    Pero es que es muy distinto el enfoque en Java que en PHP.. En java
    al fin y al cabo estás escribiendo todo en java; aquí, la parte del cliente
    la puedes escribir en HTML -lo más habitual-, en ActionScript, en Java
    (applets y/o aplicaciones que hagan peticiones vía HTTP), en Visual Basic
    (idem de idem, VB puede realizar peticiones vía HTTP)... Vamos, en todo
    aquello que "entienda" el protocolo HTTP, puede construirse sobre ellos una
    aplicación.

    Si hablamos de HTML en exclusiva, hoy en día es posible realizar
    algo así, mediante las clases PEAR (HTML_QuickForm y similares), Smarty, y
    algunas cosillas más; pero nadie -que yo sepa- lo ha hecho... Ni tengo muy
    claro si se hará.

    Es lo de siempre... ¿Cuánta gente utiliza el código que genera
    Dreamweaver para PHP ó ASP?; eso es lo más parecido a un RAD que existe en
    el mercado -de lo que yo conozco vamos-, pero el código es muy "spaguetti",
    y desde luego de óptimo tiene poco... (Sorprendentemente es mucho mejor el
    de PHP que el de ASP, a pesar de ser ASP más sencillo para muchas cosas que
    PHP... Y ser de pago y PHP no, con lo cuál Macromedia debería de haber hecho
    una "mejor" versión para ASP...)

    En fin, es un tema complejo... Yo particularmente todo lo que sean
    componentes, librerías gráficas, etc etc, uso lo menos posible, porque me
    parece que tengo poco control sobre ello (realmente no tengo control claro),
    y siempre hay cositas a nivel estético que no terminan de cerrarse con el
    uso de componentes... Por que sin ellos, no veo otra forma de crear un
    auténtico RAD para PHP y el front-end que se escoja.

    Como digo, es un tema complejo, y que da para muuuuuuuuchooooooo que
    hablar, pensar, debatir...

    Un saludo :)
    -----Mensaje original-----
    De: carlos Medina
    Enviado el: lunes, 23 de enero de 2006 16:15
    Para: php-es@lists.php.net
    Asunto: Re: [PHP-ES] Re: Framework PHP

    Precisamente Hari,
    creo que estamos de acuerdo en todos estos puntos. Mi
    pregunta (y se que
    con ello casi me OT) es la siguiente:

    Hasta que punto se puede "sacrificar" rendimiento por velocidad de
    desarrollo?. Lo mas impresionante que he visto en velocidad de
    desarrollo y rendimiento casi maximizados ha sido utilizando
    OMNIS RAD
    (de la casa Raining Data). Tengo la suerte de conocer la casa
    proveedora
    aqui en alemania y he quedado impresionado de la velocidad con que se
    programa en Omnis y la velocidad de respuesta asi como la
    confiabilidad
    del sistema. (ojo tanto web como client).

    Mis esperanzas es ver (o crear) una framework en PHP que no limite el
    rendimiento y que sea lo bastante flexible como para que cualquiera
    pueda trabajar con el comodamente y rapido.
    Quizas se tenga que invertir tiempo en disenar una IDE
    especifica para
    PHP que perfeccione estas cosas. Quizás TRUStudio o eclipse
    (son los que
    uso) :-)

    Bueno ahora si estoy OT y por eso cierro

    Saludos

    Carlos

    Hari Seldon wrote:
    Jejeje completamente de acuerdo Carlos.

    Yo no digo "no uses MVC"... Digo, úsalo, pero sabiendo
    cuáles son
    sus puntos débiles y sus puntos fuertes ;)

    Sobre el uso o no de un framework, comento el tema de
    MVC porque los
    que habeis puesto usan ese paradigma. Y ojo, me parece que
    es lo que debe de
    hacer un framework; ser lo más generalista y estándar que
    pueda; y a día de
    hoy el paradigma MVC es el más extendido, y el que más se usa.

    Pero también usamos (bueno yo uso como escritorio...)
    Windows, y no
    es lo óptimo o lo mejor.. Pero lo usamos porque es más
    cómodo (yo al menos,
    para ciertas cosas, me es más cómodo que linux, que también
    tengo, pero como
    server).

    Y aquí es dónde entra la labor del verdadero y real
    ingeniero/analista; ¿cuándo sacrificar rendimiento contra tiempo de
    desarrollo?; está claro que una aplicación hecha totalmente
    a medida, sin
    nada de código reutilizable, etc etc etc, será siempre más
    óptima que otra
    en la cuál estamos reutilizando código (el ejemplo claro lo
    tenemos con PEAR
    DB, que a pesar de que es un package -para mi forma de ver
    al menos- genial,
    que hace todo lo que debería de hacer un capa de
    abstracción de base de
    datos, sacrifica en rendimiento, pues nunca va a ser tan
    rápido como usar
    las funciones nativas para uso de mysql -o de la base de datos que
    utilizes-). Muchas veces resulta más viable sacrificar
    rendimiento por
    velocidad en desarrollo, y otras veces, no.

    La frase "solución de compromiso" es todo un lema en el buen
    ingeniero... Y lo que le hace bueno, es que llegue al
    compromiso ideal ;)
    Pero bueno, volviendo al tema, yo no digo "frameworks
    no", ni "MVC
    no".. Sino, hay que usarlos, cuándo compense hacerlo (en el
    caso de los
    frameworks), y en el caso de MVC, sabiendo lo que estamos haciendo.

    Ojo... Es mi opinión, por supuesto :)

    Un saludo a todos (y gracias por las respuestas que
    siempre son muy
    productivas)

    -----Mensaje original-----
    De: carlos Medina
    Enviado el: lunes, 23 de enero de 2006 14:42
    Para: php-es@lists.php.net
    Asunto: Re: [PHP-ES] Re: Framework PHP

    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
    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


    __________ 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


    __________ Información de NOD32 1.1375 (20060123) __________

    Este mensaje ha sido analizado con NOD32 antivirus system
    http://www.nod32.com
  • Pvergara at Jan 23, 2006 at 5:35 pm

    El Lunes, 23 de Enero de 2006 17:12, Hari Seldon escribió:
    Uhmmm lo que comentas es complejo...

    Lo único que conozco que es RAD en webapps, que sea mínimamente
    decente, es Visual Studio .NET, y particularmente, lo _odio_ .... Pero
    bueno, si que es cierto que te ahorras mucho trabajo.

    Para crear un verdadero RAD, habría que crear un montón de
    componentes, tanto a nivel servidor (un framework en PHP), como a nivel
    cliente (librerías javascript, o sea, otro framework en jS; o bien usar
    Flash con alguno de los frameworks existentes... U otros...); y todo eso,
    integrarlo con un IDE.

    El tema es interesante, pero lo veo muy complejo, y tendría que ser
    parte de un proyecto _muy_grande_ para que se llevase a buen puerto.
    Pues yo no lo veo tan lejos... el framework que mas cerquita está de conseguir
    pasar a RAD dado que su filosofía se basó muuuuyy mucho en .NET y compañía es
    el prado... que, si no quieres php y quieres html con tags de prado... los
    tienes. AAaaa ya veo a los seguidores de smarty y compañía diciéndome que
    ellos también tienen de eso :-( ... pero el planteamiento de prado la gracia
    que tiene es que no es solo la vista lo que implementa, sino el controlador y
    clases de apoyo para una generación rápida y sencilla del modelo (incluyen
    clases para autenticación, sesiones, mail, facilidades para la generación de
    tablas de datos con paginación, inserción, eliminación, etc.. que es una
    auténtica maravilla... por no hablar del soporte a la internalización y a
    todo lo que termine en "ción" que sea bueno...jejeje)

    --
    ----
    Pablo C. Vergara Castro.
    Departamento de informática.
    TQR-Software
    Tlfno.: (+34) 986 39 31 49
    Fax: (+34) 986 31 25 96


    La información transmitida va dirigida únicamente a la persona o entidad
    que se muestra como destinatario y puede contener datos confidenciales o
    privilegiados. Toda revisión, retransmisión, diseminación u otro uso o
    acción al respecto por parte de personas o entidades distintas al
    destinatario está prohibida. Si recibe esto por error, por favor
    contacte con la persona que figura como remitente y elimine el material
    de cualquier ordenador.


    The information transmitted is intended only for the person or entity to
    which it is addressed and may contain confidential and/or privileged
    material. Any review, retransmission, dissemination or other use of, or
    taking of any action in reliance upon, this information by persons or
    entities other than the intended recipient is prohibited. If you
    received this in error, please contact the sender and delete the
    material from any Computer.
  • Gustavo Pardo at Jan 23, 2006 at 5:53 pm
    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
    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
  • Jaime Reyes Aldana at Jan 23, 2006 at 7:29 pm
    Saludos lista :
    No conozco mucho Prado sin embargo he ingresado a su web site y los
    ejemplos que muestran me parecen muy simples, conoce alguno de Uds algun
    trabajo interesante desarrollado con Prado ? Que hay de simphony ?
    Nuestro desarrollo lo hacemos utilizando el framework base phpmvc
    (http://www.phpmvc.net).


    Gustavo Pardo wrote:
    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!
    --
    Saludos

    Jaime Reyes A.
  • Reynier Perez Mira at Jan 22, 2006 at 7:46 pm
    Haber, aquí les dejo el concepto de Framework según Wikipedia:

    "En el desarrollo de software, un "framework" es una estructura de soporte definida en la cual otro proyecto de software puede ser organizado y desarrollado. Típicamente, un framework puede incluir soporte de programas, librerías y un lenguaje de scripting entre otros softwares para ayudar a desarrollar y unir los diferentes componentes de un proyecto.

    Un framework representa una arquitectura de software que modela las relaciones generales de las entidades del dominio. Provee una estructura y "manera de trabajo" la cual extienden y/o utilizan las aplicaciones del dominio."

    Más o menos, te pongo un ejemplo: PRADO es un framework de PHP basado en componentes y manejo de eventos para el desarrollo rápido de aplicaciones programadas en PHP5. El mismo reconceptualiza el desarrollo de aplicaciones en términos de componentes, eventos y propiedades en lugar de procedimientos, direcciones URL y parámetros de consultas.

    Además de lo explicado arriba permite la reusabilidad del código, es fácil de usar, robusto, buen rendimiento, integración de equipo que este ultimo permite la separación del contenido de la presentación. Básicamente lo que hace Smarty.

    Bueno espero que con esto se te aclaren algunas dudas

    Salu2
    ReynierPM
    4to. año Ing. Informática
    Usuario registrado de Linux: #310201
    *************************************************************************
    El programador superhéroe aprende de compartir sus conocimientos.
    Es el referente de sus compañeros. Todo el mundo va a preguntarle
    y él, secretamente, lo fomenta porque es así como adquiere su legendaria
    sabiduría: escuchando ayudando a los demás...
  • Cristian Bullokles at Jan 22, 2006 at 10:49 pm
    Mi principal problema no es el patron MVC ya que eso lo implemento
    hace un tiempo utilizando templatepower que me parece buenisimo.
    Lo que me agradaria es un framework que posea algun modelo de
    persistencia de objetos a tablas o algo asi, que creo prado lo tenia.
    Existe alguno ?
    On 1/22/06, Reynier Perez Mira wrote:
    Haber, aquí les dejo el concepto de Framework según Wikipedia:

    "En el desarrollo de software, un "framework" es una estructura de soporte definida en la cual otro proyecto de software puede ser organizado y desarrollado. Típicamente, un framework puede incluir soporte de programas, librerías y un lenguaje de scripting entre otros softwares para ayudar a desarrollar y unir los diferentes componentes de un proyecto.

    Un framework representa una arquitectura de software que modela las relaciones generales de las entidades del dominio. Provee una estructura y "manera de trabajo" la cual extienden y/o utilizan las aplicaciones del dominio."

    Más o menos, te pongo un ejemplo: PRADO es un framework de PHP basado en componentes y manejo de eventos para el desarrollo rápido de aplicaciones programadas en PHP5. El mismo reconceptualiza el desarrollo de aplicaciones en términos de componentes, eventos y propiedades en lugar de procedimientos, direcciones URL y parámetros de consultas.

    Además de lo explicado arriba permite la reusabilidad del código, es fácil de usar, robusto, buen rendimiento, integración de equipo que este ultimo permite la separación del contenido de la presentación. Básicamente lo que hace Smarty.

    Bueno espero que con esto se te aclaren algunas dudas

    Salu2
    ReynierPM
    4to. año Ing. Informática
    Usuario registrado de Linux: #310201
    *************************************************************************
    El programador superhéroe aprende de compartir sus conocimientos.
    Es el referente de sus compañeros. Todo el mundo va a preguntarle
    y él, secretamente, lo fomenta porque es así como adquiere su legendaria
    sabiduría: escuchando ayudando a los demás...

    --
    PHP Spanish Localization Talk Mailing List (http://www.php.net/)
    To unsubscribe, visit: http://www.php.net/unsub.php

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupphp-general-es @
categoriesphp
postedJan 20, '06 at 5:23p
activeJan 23, '06 at 7:29p
posts20
users11
websitephp.net

People

Translate

site design / logo © 2022 Grokbase