Write haof XML files: carlos Medina
(
info@simply-networks.de)
Fecha: mar 24 ene 2006 - 14:55:14 CET
Hola Satyam,
creo que esto se esta poniendo bastante interesante. Pues
hace un dos
anos trabaje en un sitio en el cual la base de datos era
OMNIS de
Raining Data. Esta base de datos permite interactuar con
apache y otros
servidores Web de manera que el content es enviado
directamente al
apache luego de entrar el request.
El administrador de entonces no sabia de este feature y
programo por su
cuenta un script en PERL que el le llamaba "FIFO-dispatcher".
Lo unico
que hacia este script es redirigir los requst a un cache
immenso en el
cual almacenaba los pedidos a la base de datos en un file que
tenia una
estructura que la base de datos pudiera entender. El mismo
PERL miraba
si la base de datos "tenia tiempo" y le enviaba el query el
cual
respondido era enviado al apache.
Es un poco rudimentario lo que hizo el, y sin embargo me
parece un punto
interesante si esta manera de trabajo pudiera ser
descrita a manera de
modulo para apache o como demon (proceso) en el servidor.
Saludos
Carlos
Satyam wrote:
> No me di cuenta y al responder a
este asunto le respondí al originador
> en lugar del grupo. Fue Hari
Seldon quien me sugirio resumir y reenviar
> esta breve conversación al
grupo.
>
> Resumiendo:
>
> MI pregunta habia sido si alguien
sabe de algun Controller (la C dentro
> de MVC) que funcione integrado con
Apache, que pueda permanecer
> instanciado y despachar tareas a
los Modelos y, segun a respuesta de
> estos, despachar los Views que
corresponda. Este no podria estar
> escrito en PHP, pues
deberían interactuar con la API de Apache,
ser
> multitareas y por ello
reentrantes, pero quizas ser manejado por tablas
> independientes del lenguaje en que
los M y los V estuvieran escritos.
>
> Hari me decia que pensaba que la
facilidad del Mod_rewrite para traducir
> URLs y despachar a varias
paginas.
>
> En realidad, yo estaba pensando en
algo mas, pero aqui entramos en la
> discusion de hasta dónde
debe llegar el Controller.
>
> Cosas que pienso que podría
hacer facilmente:
>
> - Validacion de usuarios.
>
> En definitiva, todas ellas se
basan en una tabla con nombre de usuario,
> contraseña y algun
indicador de permisos que puede interpretarse ya sea
> como un nivel (valor entero donde,
por ejemplo, cero es 'invitado', 1 es
> 'usuario basico' y 99999 es
'dios') o mapeado bit a bit o el valor en si
> es una referencia a una tabla de
persmisos más detallado. En la tabla
> de despachos deberia decir que
nivel o que bits deberia tener el usuario
> para acceder a ella.
>
> - Validación de
parametros:
>
> Una tabla de descripcion de
posibles parametros con una minima
> validacion, tipo de datos, valores
posibles, minimos y maximos o
> enumeracion de alternativas,
obligatoriedad, etc.
>
> - Datos de session
>
> Dado la no-persistencia de PHP y
la incertidumbre de que el cliente
> tenga los cookies habilitados,
estos datos habitualmente son mantenidos
> por PHP en tablas en disco. Mejor
performance se podria obtener si el
> Controller los tuviera en memoria
virtual.
>
> - Timeouts.
>
> Creo que todo esto podria ser
descripto por tablas (en XML o lo que
> fuera) que el controller podria
tener cacheadas para mejorar el tiempo
> de respuesta. Ninguna de estas
requeriría código en ningun lenguaje
> particular ni impediría que
los modelos y vistas fueran luego escritos
> en tal o cual lenguaje. Si se
necesitaría una función para cada
> lenguaje soportado, que permitiera
acceder a la 'session' de este
> Controller donde estaría,
entre otros, el nombre de usuario y su nivel
> de permiso y todo lo que la
aplicación hubiera querido almacenar
allí.
>
> Por ejemplo, la
configuración de la parte de validación de
usuarrios
> indicaria los nombres de los
campos en que recibiría los datos de login,
> el nombre del campo que
indicaría hacer logout, los datos de la base
de
> datos y tabla en que se encuentran
los usuarios donde, de por si,
> supondriamos la contraseña
almacenada en MD5, los nombres de los campos
> donde estarían el nombre de
usuario y la contraseña y el nombre de otros
> campos en esa misma tabla que la
aplicación debería mantener en
> variables de sesion, disponibles
para los modelos. Alguno de esos
> campos debería contener o
un nivel o una serie de bits que deberían
> poder especificarse en la tabla de
despacho del controlador.
>
> Otra función del
controlador disponible al modelo debería ser
para
> indicarle un código de
retorno del modelo. Este podría ser usado
tanto
> para responder por error al
cliente como para derivar una consulta a
> otro modelo que prosiguiera la
transaccion.
>
> En su forma mas primitiva, el
controlador podria interactuar con los
> modelos en forma cgi, pasandole
toda la informacion por stdin y
> recibiendo todo de vuelta a traves
de un stdout con ciertas convenciones
> de formato, al menos para lo que
fuera de incumbencia al controller (por
> ejemplo, mediante headers
especificos para el controlador.)
>
> Satyam
>
>
> ----- Original Message ----- From:
"Hari Seldon"
> <
hari.seldon@telefonica.net>
> To: "'Satyam'" <
Satyam@satyam.com.ar>
> Sent: Monday, January 23, 2006
11:02 PM
> Subject: RE: [PHP-ES] Re:
Framework PHP
>
>
> Uhmm ¿te refieres a hacer
algo así como un "proxy"? Porque eso lo
> puedes hacer con un mod_rewrite, y
tendrías tu controller implementado con
> mod_rewrite ;)
>
> Vamos, se me ocurre a mi
así a bote pronto... ;)
>
> Un saludo.
>
> PD: si tal publica toda la
conversación y tu respuesta siguiente a
> la lista, y así
quién quiera puede leerla :)
>
>> -----Mensaje
original-----
>> De: Satyam [mailto:
Satyam@satyam.com.ar]
>> Enviado el: lunes, 23 de enero
de 2006 21:55
>> Para:
hari.seldon@telefonica.net
>> Asunto: Re: [PHP-ES] Re:
Framework PHP
>>
>> Acabo de darme cuenta que te
lo envié a ti personalmente en
>> lugar de a la
>> lista. Bueno, nadie en la
lista va a extrañarlo.
>>
>> No pensaba que ese modilo de
Apache fuera a estar escrito en PHP, las
>> funciones de un controlador
pueden definirse, mayormente, por tablas
>> (bueno, eso creo), de tal
forma que no tiene importancia el
>> lenguaje en que
>> este escrito.
>>
>> Satyam
>>
>> ----- Original Message -----
From: "Hari Seldon"
>> <
hari.seldon@telefonica.net>
>> To: "'Satyam'" <
Satyam@satyam.com.ar>
>> Sent: Monday, January 23, 2006
9:33 PM
>> Subject: RE: [PHP-ES] Re:
Framework PHP
>>
>>
>> Que yo sepa, no existe nada
que "arranque" con Apache, supongo que
>> tu te refieres a algo como un
servlet Java, que arranca con
>> tu app según
>> tengas definido en tu xml de
despliegue... Pero eso en PHP lo
>> veo complejo
>> -por el momento-
>>
>> Lo que si puede hacerse es un
cacheo del archivo, con las clases de
>> PEAR; aunque yo personalmente
no he probado a hacerlo.
>>
>> Re PD: predigo que el clima
por trantor será muy peligroso dentro de
>> unos miles de años..
;)
>>
>> > -----Mensaje
original-----
>> > De: Satyam
[mailto:
Satyam@satyam.com.ar]
>> > Enviado el: lunes, 23 de
enero de 2006 20:38
>> > Para:
hari.seldon@telefonica.net
>> > Asunto: Re: [PHP-ES] Re:
Framework PHP
>> >
>> > ----- Original Message
-----
>> > From: "Hari Seldon"
<
hari.seldon@telefonica.net>
>> >
>> >
>> > >
<extracto>
>> > > Yo no digo "no uses
MVC"... Digo, úsalo, pero sabiendo cuáles
son
>> > > sus puntos
débiles y sus puntos fuertes ;)
>> > >
</extracto>
>> > >
>> > >
<extracto>
>> > > Y aquí es
dónde entra la labor del verdadero y real
>> > > ingeniero/analista;
¿cuándo sacrificar rendimiento contra
>> tiempo de
>> > >
desarrollo?;
>> > >
</extracto>
>> >
>> > Aprovecho a resaltar
estos extractos de este mensaje pues me
>> > parece un
>> > recordatorio
imprescindible sobre nuestra tarea. El
>> > programador ha
de
>> > programar, eso es claro,
pero antes de ponerse a programar,
>> > alguien debe
>> > decidir si eso es
necesario y si lo es, cómo. Ese es el
>> > analista, una
>> > etapa que muy
frecuentemente se saltea en pos de lo más de
>> > moda, la ultima
>> > tecnica, lo que el
programador quiera probar a costa de su
>> > cliente, etc.
>> >
>> > Aparte, quería
preguntar despecto del controladores dentro de
>> > un esquema
>> > MVC, si no existe un
controlador integrado con Apache que
>> > pueda permanecer
>> > instanciado y sea
manejado por tablas que puedan estar cacheadas
>> > permanentemente. Vistas y
modelos deben instanciarse
>> > individualmente
para
>> > cada cliente, eso no
tiene remedio.
>> >
>> > Satyam
>> >
>> > PD: Como está el
clima en Trantor?
>> >
>> >
>> > __________
Información de NOD32 1.1375 (20060123)
__________
>> >
>> > Este mensaje ha sido
analizado con NOD32 antivirus system
>> > http://www.nod32.com
>> >
>> >
>>
>>
>>
>> __________ 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