Write haof XML files: Cristian Bullokles
(
cristian.bullokles@gmail.com)
Fecha: lun 23 ene 2006 - 13:39:40 CET
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 <
interco@linuxbaja.org> 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
[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
> >
> >
>
> --
> 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
Este archivo fue generado por hypermail 2.1.7 : sáb 18 mar 2006 - 18:23:29 CET