Write haof XML files: Hari Seldon
(
hari.seldon@telefonica.net)
Fecha: lun 23 ene 2006 - 17:12:41 CET
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
[mailto:
info@simply-networks.de]
> 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
[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
>
>
> __________ Información de
NOD32 1.1375 (20060123) __________
>
> 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