xml - ¿Algún sitio grande que use Client Side XSLT?
frameworks (7)
Últimamente, he estado reflexionando sobre la arquitectura poco convencional de construir XML sin procesar en el lado del servidor, y luego usando una hoja de estilos XSLT en el cliente para transformar el XML en la IU completa. Por supuesto, un mecanismo de reserva debería existir si el cliente no fuera capaz de XSLT del lado del cliente, en cuyo caso simplemente lo transformaríamos para ellos en el lado del servidor.
Ya estoy íntimamente familiarizado con XSLT, y este enfoque parece ser una separación clara de presentación y contenido, forzando por completo los datos en XML y usando XSLT para la presentación.
También soy consciente de que esto agrega una capa adicional de complejidad a la aplicación, que es solo otra parte móvil que puede fallar.
Mi pregunta es: ¿hay algún gran nombre o sitios de gran tráfico que utilicen este enfoque? De ser así, ¿qué limitaciones / lecciones aprendidas le quitaron?
Gracias a Internet, Zach
Actualmente estoy ejecutando algunas páginas menores con XSLT del lado del cliente, todas en sueco (lillemanfestivalen.se, resihop.nu y proyectos beta). Mi mayor preocupación fue que Google no indexó el contenido de mis páginas, solo el XML sin la transformación. Sin embargo, desde que lancé resihop.nu hace una semana, ¡aparece en Google con transformación! :RE
Ahora mi otra preocupación es Facebook y otros sitios sociales, que no entienden cómo manejarlo. Sin embargo, todavía creo que los lados positivos son mayores que los lados negativos. La fabulosa velocidad y separación que obtengo es impresionante. Y con resihop.nu, ni siquiera desarrollo una API separada, solo señalo a los desarrolladores al sitio en sí. (Sin embargo, se necesitará más trabajo allí para hacerlo bien)
Como otras personas han mencionado, Blizzard tiene muchos sitios que son xsl del lado del cliente. Yo recomendaría evitar el lado del cliente xsl. Es una idea genial, pero hay muchos errores inusuales que necesita solucionar.
En Firefox, cualquier javascript que use document.write destruirá el DOM. Además, el complemento noscript para firefox detiene el lado del cliente xsl. En ambos casos, el usuario no verá nada. No parece haber una manera de detectar este tipo de error, por lo que una caída no funcionará.
En IE, si tiene algo que hace una redirección 30x a algo de un origen diferente (que va de http a https o cruzando subdominios), recibirá un error por violar la misma política de origen . Realmente no violó la misma política de origen, pero IE actúa como lo hizo. Por ejemplo, si va a http://foo.example.com/login y eso hace una redirección 302 a https://bar.example.com/login.xml , IE tratará el xsl como si viniera del bar .example.com y tratará el xml como si viniera de foo.example.com. Por lo tanto, tendrá que volver a algo así como una meta actualización para sus redireccionamientos.
Estas son las cosas que se me ocurrieron fuera de mi cabeza. Es una idea clara, pero tenga en cuenta estos problemas.
Estoy de acuerdo con la respuesta de Elijah. Creo que usar XSLT del lado del cliente es un trabajo difícil. Tienes que hacer una gran cantidad de control de calidad para ello. Pero mientras que con el lado del servidor, no haces ese control de calidad. Tienes que ocuparte de todo tipo de clientes y posibilidades mientras usas el lado del cliente. Es posible que su código se rompa al usar XSLT del lado del cliente.
La compañía en la que trabajé en 2001 lanzó un producto de servidor que implementó exactamente la arquitectura que describe. Tuvimos muy buen éxito descargando el procesamiento a los clientes. Además, al hacer la detección del cliente utilizando el agente de usuario HTTP, pudimos usar el procesamiento XSL del lado del servidor para atender a clientes muy específicos, como los teléfonos celulares japoneses. Creo que los sitios / servicios / productos que usan esta técnica lo hacen de manera bastante transparente para los clientes. Sin embargo, creo que últimamente la tendencia es hacer el procesamiento en el lado del servidor para que no tenga que depender ni probar las implementaciones particulares de XSL para una variedad de clientes y obtendrá soporte para algunas extensiones XSL que no podría para usar al admitir la gran mayoría de navegadores.
Sé que no estoy respondiendo directamente a su pregunta de nombrar algunos sitios de renombre, pero espero ofrecer algo de valor para el problema. Entonces, básicamente, mi punto es que a menos que el ahorro de rendimiento de hacer el procesamiento de su plantilla sea más valioso que tener que QA, soporte y desarrollo para tres o cuatro navegadores sin extensiones, entonces debe quedarse con el procesamiento del lado del servidor.
No conozco ningún gran sitio web público que use la transformada XSLT del lado del cliente (bueno, excepto World of Warcraft mencionado por Joel :-). Entonces no puedo responder tu pregunta directamente.
Sin embargo, de vez en cuando yo mismo estaba reflexionando sobre la misma pregunta, y tengo la hipótesis de que el número de tales sitios en Internet debe ser muy cercano a cero. :-)
La versión corta de mi teoría detrás de esta hipótesis es la siguiente: con la excepción de algunos casos bastante exóticos, la provisión de la opción XSLT del lado del cliente simplemente no vale la pena. :-)
No pude decirle en detalle cómo se implementó, pero World of Warcraft es bastante grande y de alto tráfico, y su sitio web se implementa como usted describe.
Puedo ser parcial cuando digo esto, pero trabajando en una aplicación web que hace esto, lo odio. La única razón por la que es incluso viable es porque los clientes son solo IE6 +. Incluso entonces, hay problemas con eso. Encuentro que XSLT es muy difícil y sugeriría que hicieras esto para obtener una buena herramienta para depurar y editar XSLT. ¿Por qué no usar JSON y jquery? Debe tener una mayor variabilidad estándar y menor en el lado del cliente.