por
pobrecito hablador
el Miércoles, 15 Junio de 2005, 14:58h
(#529317)
Asi que no te metas en un lio por "innovar".
De todas formas, yo te diria que no mezclaras muchas cosas, que si quieres usar ADO.NET para leer la base de datos tires con .NET para todo lo demas. Si no quieres una parte de .NET, no lo uses porque ya sabes, "lo importante es no mezclar".
Por lo demas, la arquitectura de la aplicacion me parece bien, incluso puedes distribuirla por distintas maquinas y usar SOAP me parece una buena idea.
En cuanto a usar XML+XSL me parece un acierto, pero debes tenerlo en cuenta desde el principio para tooooda la aplicacion, y ademas tener en cuenta que hay navegadores que no mezclan en local XML+XSL, asi que tendras que hacerlo en el servidor.
Si tu aplicacion devuelve al cliente los datos en un XML, añadiendole una linea que apunte a la XSL que mas te guste, el cliente lo formateara en local. ¿En que orden? Tu le das el XML desde una pagina DINAMICA y el empieza a procesarlo mientras el servidor web/servidor de aplicaciones atiende a otros. El navegador se encuentra que necesita la XSL, asi que la pide como una pagina ESTATICA, y el servidor web (pues esto es estatico) se la da. El navegador sigue mezclando y entonces empieza a pedir imagenes, css, flash... como si fuera una pagina normal. ¿Ventajas? TODO menos los datos propiamente dichos es estatico, asi que se cachea y las proximas veces no te las pediran, asi que ahorras ancho de banda.
Siempre y cuando los clientes sean capaces de mezclar XML+XSL en local, que por ejemplo el opera ni puede ni podra. Eso lo tienes que tener previsto, asi que tienes que sacar el navegador que estan usando y en funcion de eso devolver el XML como te he dicho o mezclarlo tu en el servidor, que no te va a ahorrar ancho de banda y sera mas costoso en CPU. Seria algo asi coo tener una lista de navegadores capaces e incapaces y si el cliente tiene uno capaz, le añades la linea del XSL y si no lo mezclas tu para dar HTML.
Evalua que tipo de clientes tendras y si tendran navegadores capaces de mezclar en local para no cagarla.
En cuanto a devolver un PDF a partir de un XML es facil pero LO TIENES QUE HACER EN LOCAL. Hay por ahi un jar que lo hace. Yo lo encontre en Cocoon, un proyecto de apache en java que no se si se mantiene, pero seguro que hay equivalentes en otros lenguajes. Pro cierto, la XSL era un puto infierno.
Espero haber sido de ayuda.
PD: Supongo que tu problema es de trabajo, asi que dejate de tonterias y usa lo que mejor te venga, tanto como si es libre como si no.
En cuanto a devolver un PDF a partir de un XML es facil pero LO TIENES QUE HACER EN LOCAL. Hay por ahi un jar que lo hace. Yo lo encontre en Cocoon, un proyecto de apache en java que no se si se mantiene, pero seguro que hay equivalentes en otros lenguajes. Pro cierto, la XSL era un puto infierno.
Te veo un poco pez
(Puntos:0)De todas formas, yo te diria que no mezclaras muchas cosas, que si quieres usar ADO.NET para leer la base de datos tires con .NET para todo lo demas. Si no quieres una parte de .NET, no lo uses porque ya sabes, "lo importante es no mezclar".
Por lo demas, la arquitectura de la aplicacion me parece bien, incluso puedes distribuirla por distintas maquinas y usar SOAP me parece una buena idea.
En cuanto a usar XML+XSL me parece un acierto, pero debes tenerlo en cuenta desde el principio para tooooda la aplicacion, y ademas tener en cuenta que hay navegadores que no mezclan en local XML+XSL, asi que tendras que hacerlo en el servidor.
Si tu aplicacion devuelve al cliente los datos en un XML, añadiendole una linea que apunte a la XSL que mas te guste, el cliente lo formateara en local. ¿En que orden? Tu le das el XML desde una pagina DINAMICA y el empieza a procesarlo mientras el servidor web/servidor de aplicaciones atiende a otros. El navegador se encuentra que necesita la XSL, asi que la pide como una pagina ESTATICA, y el servidor web (pues esto es estatico) se la da. El navegador sigue mezclando y entonces empieza a pedir imagenes, css, flash... como si fuera una pagina normal. ¿Ventajas? TODO menos los datos propiamente dichos es estatico, asi que se cachea y las proximas veces no te las pediran, asi que ahorras ancho de banda.
Siempre y cuando los clientes sean capaces de mezclar XML+XSL en local, que por ejemplo el opera ni puede ni podra. Eso lo tienes que tener previsto, asi que tienes que sacar el navegador que estan usando y en funcion de eso devolver el XML como te he dicho o mezclarlo tu en el servidor, que no te va a ahorrar ancho de banda y sera mas costoso en CPU. Seria algo asi coo tener una lista de navegadores capaces e incapaces y si el cliente tiene uno capaz, le añades la linea del XSL y si no lo mezclas tu para dar HTML.
Evalua que tipo de clientes tendras y si tendran navegadores capaces de mezclar en local para no cagarla.
En cuanto a devolver un PDF a partir de un XML es facil pero LO TIENES QUE HACER EN LOCAL. Hay por ahi un jar que lo hace. Yo lo encontre en Cocoon, un proyecto de apache en java que no se si se mantiene, pero seguro que hay equivalentes en otros lenguajes. Pro cierto, la XSL era un puto infierno.
Espero haber sido de ayuda.
PD: Supongo que tu problema es de trabajo, asi que dejate de tonterias y usa lo que mejor te venga, tanto como si es libre como si no.
Re:Te veo un poco pez
(Puntos:1)( http://barrapunto.com/~payo_ranger | Última bitácora: Sábado, 25 Diciembre de 2010, 07:17h )
XML + XSL = .FO
.FO + FOP [apache.org] = PDF
Saludos