Write haof XML files: carlos Medina
(
info@simply-networks.de)
Fecha: lun 23 ene 2006 - 16:14:59 CET
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
[mailto:
info@simply-networks.de]
>>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
[mailto:
info@simply-networks.de]
>>>>Enviado el: lunes, 23
de enero de 2006 9:53
>>>>Para:
php-es@lists.php.net
>>>>Asunto: [PHP-ES] Re:
Framework PHP
>>>>
>>>>Hola Lista,
>>>>
>>>>Como dijo Gustavo
Prado, un framework es un marco de trabajo
>>>>en el cual
>>>>ya se encuentran muchas
clases "precocinadas" para que el
>>>>programador de
>>>>sitios grandes tenga un
instrumento medio standard para su
>>>>aplicacion(me
>>>>refiero a aplicaciones
en la cual trabajen varios programadores).
>>>>En realidad la mayoria
de los trabajos en PHP son muy "sencillos":
>>>>formularios, foros,
rutina mail y otros. La mayoria de los
>>>>casos cuando
>>>>se comienza un
proyecto, nunca se sabe bien, que tan grande
>>>>va a llegar
>>>>a ser. En estos casos
se utiliza un framework para que el
>>
>>desarrollo
>>
>>>>tenga ya desde su base
una estructura en la cual el programador
>>>>(sobretodo el nuevo)
pueda "entrar" al desarrollo con mas
>>>>facilidad y se
>>>>tenga una base de las
clases mas usadas.
>>>>
>>>>En un proyecto de gran
alcance en el cual trabajo
>>
>>acualmente (combina
>>
>>>>PHP, Java,
JavaScript,PERL, C++ y ShellScript de integracion
>>>>en sistemas
>>>>linux, AIX, IRIX,
Windows y MAC X) utilizamos el framework
>>>>seagull, que
>>>>segun el cliente es uno
de los mas potentes pero al mismo
>>
>>tiempo mas
>>
>>>>entendibles.
>>>>
>>>>Cuando hay que
desarrollar paginas nuevas o nuevos features
>>>>se tienen a
>>>>la mano una serie de
herramientas como la conexion al DB
>>>>(independientemente de
si es DB2, MySQL u ORACLE) con las
>>>>cuales manejo
>>>>los query sin tener que
escribir el consabido "SELECT * FROM"...
>>>>
>>>>A mi me gusta
>>>>
>>>>Saludos
>>>>
>>>>Carlos
>>>>
>>>>
>>>>Daniel Naranjo
wrote:
>>>>
>>>>
>>>>>Hola, disculpa mi
ignorancia, pero para que sirve un
>>>>
>>>>framework para php?
actualmente desarrollo en php 4, pero no
>>>>entiendo muy bien el
uso de un framework?
>>>>
>>>>
>>>>>Salu2
>>>>>Daniel
>>>>>
>>>>
>>>>--
>>>>PHP Spanish
Localization Talk Mailing List (http://www.php.net/)
>>>>To unsubscribe, visit:
http://www.php.net/unsub.php
>>>>
>>>>
>>>>__________
Información de NOD32 1.1373 (20060120)
__________
>>>>
>>>>Este mensaje ha sido
analizado con NOD32 antivirus system
>>>>http://www.nod32.com
>>>>
>>>>
>>
>>--
>>PHP Spanish Localization Talk
Mailing List (http://www.php.net/)
>>To unsubscribe, visit:
http://www.php.net/unsub.php
>>
>>
>>__________ Información
de NOD32 1.1373 (20060120) __________
>>
>>Este mensaje ha sido analizado
con NOD32 antivirus system
>>http://www.nod32.com
>>
>>
-- PHP Spanish Localization Talk Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Este archivo fue generado por hypermail 2.1.7 : sáb 18 mar 2006 - 18:23:29 CET