Publicado un nuevo número del podcast de javaHispano. En esta ocasión entrevistaremos a Marioko que nos explicará su experiencia con ZK para desarrollo de aplicaciones web RIAA. Durante el podcast explicará algunos componentes y productos, integración con otros frameworks, ajax, realización de informes y, finalmente, hablaremos de la documentación disponible para iniciarse.
Links de interés:
Etiquetas: j2ee, zk, podcast, riaa
Que bien, desde que Marioko dijo que deseaba hacer un podcast a cerca de su introduccion a este framework, lo esperaba, gracias jH, gracias Marioko.
algo que se me olvido mencionar es que en ZK las ventanas modales son realmente modales, es decir, que no bloquean unicamente la interaz del usuario, ademas bloquean el proceso que invoca la ventana modal. Por ejemplo con el MessageBox
int respuesta = MessageBox.showMessage(....); //aqui se bloquea
if(respuesta == YES){
//hacer algo
}
esto es gracias al soporte multi-thread que tiene ZK para gestionar eventos y es bastante util cuando quieres hacer cosas complejas, por ejemplo, que el usuario en alguna ventana modal ingrese algunos datos del mismo formulario, o para hacer un buscador generico que retorne los datos que selecciono el usuario. Yo me hice algo asi, se llama EntityPicker que permite a usuario satisfacer una dependencia en algun formulario. Ej:
//este metodo se invoca al presionar un boton
public void seleccionarEmpresa(){
Empresa emp = EntityPicker.pick(Empresa.class,"ID","Nombre","Direccion","Representante");
contrato.setEmpresa(emp);
}
El metodo pick muestra una ventana modal en la interfaz de usuario con un buscador generico y una tabla, los Strings que se le pasan como parametro son los datos de la entidad Empresa que quieres que se muestren y ademas por los cuales quieres que se busque.
Hola Marioko, soy el anonimo1, (cokies en mi empres no funcionan por eso no anda bien mi resgistro). hay alguna parte donde pueda escribirte para preguntarte dudas y sobre temas no solo de tu experiencia con ZK (si es posible), ademas con ICEFaces, soy de medellin.
Saludo Paisano
JC
Muy buen podcast. Muchas gracias Mario y Jorge.
Y wow, excelente la potencia y flexibilidad de ZK...
@Anonimo1: claro mi mail es: marioko EN javahispano.org
Me queda una duda, he visto la documentación para iniciarse, pero el entorno de desarrollo no dispone de un IDE WYSIWYG para el diseño grafico y otra cosa... eclipse es la unica solución?
Interesante es que en el sitio de ZK digan que "The best way to use Ajax is to not know of its existence."
http://docs.zkoss.org/wiki/ZK_Architecture_Overview
Después de escuchar el podcast me quedé con la duda: Yo pensaba que ZK funcionaba al estilo de GWT, tomando el código escrito en Java para la interfaz (en el servidor) y "traduciéndolo" a código que fuera ejecutado en javascript en el navegador client. Pero parece que me equivoqué.
Revisando el gráfico de arquitectura de ZK en el link que puse anteriormente, me parece entender que el motor de ZK del lado del servidor se encarga de conversar con la definición de la interfaz definida en elgún lenguaje, ya sea Java, XUL u otro, y de esta forma el motor es quien generaría una página HTM, en donde controlaría el árbol DOM mediante eventos desde el navegador cliente hacia el servidor.
¿No es ésta la forma en que trabaja ItsNat?
He de decir que yo no he visto ni probado nada de ZK ni tampoco de ItsNat, solamente hablo desde lo que he escuchado en los podcast. Sería interesante saber qué opina jmarranz acerca de ZK, si le parece un framework interesante, recomendable, y en qué casos sería apto para crear aplicaciones web.
Uff, ante todo mi opinión es inevitablemente parcial por razones obvias (aunque difícilmente vas a encontrar una opinión que trate de ser objetiva en estos temas).
Hasta donde yo se ZK es un framework céntrico en el servidor, es decir, es más parecido a IceFaces, RichFaces etc que a GWT. En los frameworks céntricos en el servidor la mayor parte del trabajo se cocina en el servidor, todo enfoque tiene sus ventajas y sus pegas, la ventaja más importante es que como los datos están en el servidor la salida y entrada de datos en la vista es mucho más sencilla que con un enfoque céntrico en el cliente al no requerir puentes explícitos por parte del programador. Por eso los de ZK se chulean con lo de "The best way to use Ajax...", esa chulería es propia de cualquier framework AJAX céntrico en el servidor. El precio a pagar de ser céntrico en el servidor es que puede haber más requests cliente/servidor y suelen dar menos libertad al programador (excepto el caso de ItsNat), aunque en esto de la libertad es discutible pues hay frameworks cliente que son también muy poco flexibles a cambio de ser muy sofisticados (hablo de los componentes no de la API básica).
Lo que tienes que tener claro antes de nada es si prefieres un enfoque céntrico en el servidor o céntrico en el cliente, si estás dispuesto a programar en JavaScript (céntrico en el cliente) o en Java/lenguaje de servidor (salvo el caso de GWT que traduce Java a JavaScript), si estás dispuesto a pensar en puentes cliente/servidor de comunicación de datos (enfoque céntrico en el cliente) o te quieres olvidar de puentes y optar por un enfoque en donde una representación de la vista, la lógica de la vista y los datos están juntos en el servidor. Normalmente los frameworks AJAX céntricos en el servidor tienden a crear la ilusión de que el navegador está en el servidor tanto respecto a la entrada de datos como en la salida, ItsNat es el caso más extremo y "natural" de este enfoque.
Si tienes claro que tu vida está en el servidor es cuando tienes que plantearte si ZK es tu opción.
ZK está en la línea de casi todos los frameworks AJAX centricos en el servidor: ofrecer componentes visuales precocinados cada vez más y más sofisticados a base de custom tags. En el caso de ZK los custom tags están inspirados en el estándar XUL de FireFox pero generando HTML y JavaScript que pueda consumier cualquier navegador, esto no significa que siga el estándar XUL a pies juntillas, tampoco esa es la intención.
Como todo, tiene sus ventajas y sus inconvenientes, las ventajas de los componentes precocinados es que puedes impresionar a tu jefe/cliente normalmente con poco trabajo porque hay mucha funcionalidad ya hecha y un aspecto visual muy atractivo. Pero también tiene inconvenientes:
* Son muy inflexibles, el layout (el HTML generado) está totalmente controlado por el framework, olvídate de intentar modificar algo via JavaScript porque lo más probable es que lo rompas, eso significa que si tu jefe/cliente quiere una variación en el comportamiento del componente lo mejor es que les convenzas de que no es posible o intentes comprender la funcionalidad interna y rezar de que puedas cambiarla o busques otro trabajo.
* Como son tremendamente sofisticados la tolerancia a funcionar en muchos navegadores es inviable, olvídate de muchos navegadores móviles, además los componentes suelen ser pesados tanto en markup como en cantidad de JavaScript que se carga en el cliente (esto va por lo de los móviles).
* Imponen claramente una estética, dicha estética es muy difícil de cambiar, has de casarte con ella. Esto lo hace poco apto para sitios web (no hablo de aplicaciones web).
* Normalmente frameworks como ZK requieren un control absoluto de la página web por lo que es poco viable hacer sitios web pues la organización de la página la dicta el framework.
En el caso concreto de ZK, ZK promueve la mezcla de markup de vista y lógica de vista, yo creo que mucho más que JSF, a mi particularmente no me gusta pues no favorece en absoluto la reutilización y la separación de responsabilidades, pero en ese tema hay gustos.
Respecto a lo de controlar el DOM en el cliente, eso es algo que obviamente todo framework AJAX hace (tipo servidor o tipo cliente).
En el caso de los frameworks cliente la vista está únicamente en el cliente y la lógica de la vista está en JavaScript, ya sea escrita directamente por el programador o generada a partir de Java con GWT.
En el caso de los frameworks servidor el JavaScript está totalmente controlado por el framework, el servidor de alguna forma conoce cual es el estado de la vista en el cliente, la representación de la vista cliente en el servidor depende del framework y no necesariamente ha de ser una copia de lo que hay en el cliente, el framework generará el adecuado JavaScript para modificar la vista de acuerdo con las acciones del usuario (también puede haber JavaScript en el cliente para cambios que no requieran el servidor). Normalmente la capacidad de actuar sobre la vista está limitada a las formas que conoce el framework, el programador no tiene un control a medida de la vista.
En el caso de ItsNat el árbol DOM del cliente está repetido exactamente en el servidor, más bien es al revés es el DOM cliente un reflejo del DOM servidor, tal que la ilusión de que el navegador está en el servidor (propio de los frameworks céntricos en servidor) es extrema en el caso de ItsNat, pues todo cambio en el DOM del servidor se manifiesta automáticamente en el cliente, pues el framework genera el JavaScript correspondiente "por debajo". En el servidor se carga un HTML puro sin lógica (el template) de similar forma que el navegador carga la página inicial, y la lógica está en Java interactuando con el DOM del servidor usando la API Java W3C DOM Core y HTML y registrando event listeners y recibiendo eventos usando la API Java W3C DOM Events, los eventos del navegador que tienen algún listener en el servidor son enviados por AJAX al servidor y convertidos en Java W3C DOM Events en el servidor creando la ilusión de que el botón DOM (o cualquier elemento en general) del servidor ha sido pulsado en el servidor. En resumen viene a ser un DHTML en el servidor, se trabaja igual que en el cliente usando JavaScript pero en el servidor con Java y APIs universales (ItsNat se encarga de gestionar los diferentes navegadores) y con la ventaja de que los datos están junto a la vista y no son necesarios puentes.
¿Cual es la diferencia fundamental con ZK (y IceFaces, RichFaces etc)? La libertad. En el caso de ItsNat la libertad es casi absoluta, ItsNat no impone componentes, ni estéticas, los componentes son optativos y sencillos, no imponen una vista concreta, se busca que sea "enchufable". Otra ventaja es poder programar aplicaciones Single Page Interface en un montón de navegadores en donde casi nunca es necesario código específico respecto al navegador concreto.
La pega más importante de ItsNat es que tienes que trabajarte la estética, el layout HTML es cosa tuya con total libertad, pero tienes que trabajártelo tú. Algunos efectos especiales en donde no sea necesario comunicarse con el servidor pueden hacerse a través de código JavaScript propio, con cierto cuidado es posible mezclar ItsNat con un framework JavaScript, aunque te aseguro que en algunos navegadores móviles la única opción posible es que ItsNat controle todo y que todo cambio se haga a través de ItsNat en el servidor, ItsNat ya suda (y yo) por ti, doy fe de que nunca verás un framework JavaScript que haga algo útil en navegadores como UCWEB, Motorola Symphony o Pocket IE (WM 6 y 6.1), con mucho sudor y lágrimas ItsNat 0.7 es capaz de ejecutar el Feature Showcase en estos navegadores (en el caso de Pocket IE roza el milagro).
En pocas palabras, ItsNat viene a ser una paleta de pintor, ZK y similares vienen a ser cuadros en piezas en donde puedes combinar piezas y dar algunos retoques a las mismas. Todo depende de lo que quieras y/o necesites.
Yo podría intentar seguir la filosofía de ZK y sus primos y apostar por hacer componentes más y más sofisticados, más y más rígidos, de hecho la fundación de ItsNat me permite ese camino en un ámbito de navegadores mucho más amplio que la "competencia", pero no me interesa (por ahora), pues dejaría detrás a gente que no le interesa en absoluto el barroquismo de otros frameworks y quiere programar el tipo de aplicaciones/sitios web del futuro (Single Page Interface, Comet, server-sent events, SVG etc) con absoluto control en el que la estética es cosa de los diseñadores web.
Pero si quieres una herramienta muy productiva y muy vistosa a corto plazo (aunque indomable a largo plazo), ZK es mejor opción, aunque a mi personalmente desde la distancia me gusta algo más los primos AJAX de JSF quizás por aquello de que no mezclan tanto la vista con la lógica.
wow, al comentario de jmarraz solo hay que agregarle el titulo: "Deficiencias y ventajas de los frameworks centricos en el cliente y el servidor" y listo, el articulo del mes del portal ;-) ojo no lo digo por lo extenso sino por el contenido bien explicado!
En el caso de ZK5 (la verson actual no) la integracion con el cliente es mucho mas flexible, solo mencionar que te dejan utilizar JQuery para modificar lo que quieras, y si usas Jquery tienes control "absoluto" del cliente. Es posible ademas crear componentes desde JavaScript en el cliente y conectarlos con el servidor, incluso tiene una version que se llama ZK Light que es una simple libreria javascript para usar todos los componentes pero centrado en el cliente y asi poder usar cualquier otra tecnologia en el servidor.
Como mencione en el podcast eso lo llaman Client+Server Fusion que en pocas palabras es convertir a ZK en un framewokr centrico en el cliente y/o el servidor dependiendo de lo que se necesite.
Y sobre la forma de utilizarlo, es posible implementar una solucion MVC pura (totalmente desacoplada), se puede ademas incluir paginas .ZUL en archivos .jar y asi crear modulos independientes que instalen incluso hasta las vistas. Otra cosa que tendra la version 5 es integracion con GWT, me imagino que sera algo asi como usar componentes GWT en ZK o viseversa
saludos
@Marioko: Solo mencionar que te dejan utilizar JQuery para modificar lo que quieras, y si usas Jquery tienes control "absoluto" del cliente
No te quiero desilusionar Marioko pero me juego el cuello a que eso no es verdad. Como decía más arriba nada impide que puedas meter JavaScript propio, JQuery o el framework que quieras si el framework te permite un resquicio de HTML libre (para insertar un script etc) o en general algún mecanismo de inserción de JavaScript. Está claro que ese JavaScript tuyo podrá hacer lo que le de la gana, aparentemente tienes control absoluto del cliente, pero en la práctica cualquier intento de tocar libremente el DOM de los componentes de ZK cargados en el cliente tiene un altísimo riesgo de romper el componente.
El artículo que mencionas no tiene nada que ver con lo de "control absoluto", lo que han conseguido es modelizar el código JavaScript que se carga en el cliente, para realizar las acciones que son instruidas desde el el servidor, como una API pública y supongo que documentada (es decir hasta ahora esa librería era interna no documentada), a través de dicha API pública podrás hacer desde JavaScript las mismas acciones que se realizan desde el servidor (y que son convertidas en similares llamadas en el cliente). En cierto modo están "copiando" la idea de Ext-JS o SmartClient pero al revés, estos nacieron como librerías JavaScript y crearon luego APIs en el servidor (tipo JSF por ejemplo), también creo haber visto esta idea en Echo.
En resumen, el control que tendrás con código JavaScript en el cliente será exactamente el mismo que tienes ahora desde el servidor, y con JQuery dudo que puedas hacer "sensatamente" algo más que buscar los nodos padre de los componentes a través de sus ids. Prueba con el FireFox a ver un trozo de código generado HTML de ZK usando el "Inspect Element" de FireBug y entenderas lo que estoy diciendo.
La idea no es absoluto mala pues consiguen situar ZK como un framework más céntrico en el cliente, compitiendo con Ext-JS, Dojo etc.
Por poner una pega, como en la v5 (no se si lo hacían antes de otra forma) el renderizado de la vista se hace totalmente en el cliente lo hace más lento y pesado y por tanto en mi opinión menos apto para el mundo de los móviles (los móviles agradecen muchísimo que el trabajo se lo des hecho desde el servidor). En ItsNat yo evito lo más posible esta técnica, es decir, mínimo JavaScript en el cliente, contemplar toda la casuística de problemas de los montones de navegadores que hay en el mercado daría lugar a un monstruo de JavaScript, prefiero que ese monstruo esté en Java el cual controlo mucho mejor y el cual no necesita enviarse al cliente, pero ItsNat tiene diferentes objetivos y requisitos que ZK, en ZK el "más madera" está permitido.
Marioko:
Hazte un ScreenCast con un ejemplito !!!!
GRACIAS
@jmarranz: No te quiero desilusionar Marioko pero me juego el cuello a que eso no es verdad...
;-( jeje por eso coloque """"absoluto""" porque igual no lo he probado con mis propias manos, y es ademas es logico que si quieren mantener cierto estado sincronizado con el servidor necesitan limitar algunas cosas para que el programador no modifique cosas que dañarian la sincronizacion.
En mi caso personal a mi me sigue gustando todo lo centrico en el server, sencillamente porque es muuucho mas facil de programar y entre menos me toque usar javascript pues mucho mejor, asi me concentro en otras cosas.
@itubal: en la pagina de ZK hay un monton de Small Talks y casi todas tiene screencasts.
Excelentes comentarios@jmarranz y @Marioko, veo que estamos complementando el podcast y eso me alegra. Ambos dan excelentes comentarios!
Sólo agregar que la frase que dijo remoh en el podcast n°17 de JavaHispano:
(39:35)
Alfredo Casado: (hablando de GWT)... aunque... que nadie se engañe: si tú quieres desarrollar aplicaciones web ricas, tienes que aprender a desarrollar aplicaciones web ricas. Parece de perogrullo, pero que nadie piense que puede empezar a hacerlo "hala, venga" y tirarse al río...
Y me sorprende la frase de la gente de ZK que diga que la mejor forma de usar Ajax en no saber que existe! :S Rarísimo por decir lo menos.
@Germang: sólo agregar que la frase que dijo remoh en el podcast n°17 de JavaHispano:
eso es cierto Germang, pero lo mismo se podria aplicar a: "si quieres desarrollar aplicaciones ${VARX}, tienes que aprender a desarrollar aplicaciones ${VARX}"
Aunque en ZK, icefaces y compañia te escondan todo lo que tiene que ver con Ajax siempre es bueno conocer un poco de lo que ocurre por debajo, es el mismo caso de Hibernate y JDBC. Pero eso no significa que tengas que preocuparte demasiado por eso. Es como el caso de si contratas a alguien que pueda programar muy bien aplicaciones web rica, tu no necesitas saber como hace las cosas, a ti solo te interesa que el resultado final sea el esperado, la app sea rapida y robusta. El caso de los frameworks que esconden muchas cosas es lo mismo. ZK (y el monton de gente que esta detras) saben muy bien como hacer app web ricas, asi para que molestarme por cosas que me quitan tiempo.
Saludos...
Hola marioko, tu que has probado icefaces y zk, cual consideras que es mejor, almenos en tu punto de vista , o tu opinion en lo personal ?¿
Aunque llevo casi dos años usando icefaces y tan solo 2 meses usando ZK te puedo asegurar que ZK es mucho mejor. Pero en cuanto a Ajax Push (comet) se refiere ICEfaces le lleva la delantera por muuuucho.
es mejor porque:
Marioko los de IceFaces han puesto en su oficina una diana con tu foto :)
jejejej pues lo unico que tendran de diana sera mi mail y mi nombre!! XD mmmm aunque pensandolo bien tambien tienen mi direccion exacta (de cuando me enviaron la camiseta) 8-S
de todas formas a mi me toca seguir usando icefaces por un buen tiempo, hay muchas cosas que mantener... ,-)
Buenos dias, pues yo en los ultimos 4 años he usado JSF, My Faces, GWT y ZK, de esta experiencia puedo decir que, para aplicaciones web, lo mas sencillo que existe es ZK. JSF es muy robusto y completo pero hay que aprender bastante para domarlo...
Oigan, buenas noticias, este podcast aparece en la pagina principal de ZK www.zkoss.org como JavaHispano podcast - A Spanish introduction to ZK
Gracias a Jorge Rubira y Javahispano por la calidad de sus podcasts!!! :-)
Al contrario! Gracias a ti ;)
Saludos...
Hola marioko, al hilo de una pregunta anterior tu que prefieres gwt o zk ????? Muchas gracias.
hola Ivicente..
pues la respuesta es obvia, yo prefiero ZK y basicamente por lo que comento jmarranz en el post 22/09/2009 22:21. ZK en principio es una tecnologia centrada en el servidor, es decir, que todo se programa y ejecuta en el server y al cliente solo se envian datos. Esto te permite conectar los componentes visuales (databinding) directamente a clases java que se estan ejecutando en el servidor, por lo que a ti no te toca programar ningun RPC ni nada por el estilo porque eso lo hace el framework por ti.
Gwt y compañia (SmartGWT por ejemplo) tienen excelentes funcionalidades y muuuuchos componentes, y hasta ZK tendra integracion con GWT, pero para mi tener que escribir mas codigo para obtener datos del servidor es perder tiempo.
En pocas palabras es cuestion de gustos
cordial saludo a todos
jmarranz quiero hacerte la siguiente pregunta para obtener un mejor rendimiento es mejor usar framework céntrico en el servidor o en el cliente ?, y si se debe evitar lo mayor posible desplegar javascript en el cliente para el caso de aplicaciones moviles? y si alguno de la comunidad conoce de un framework que cumpla con las espectativas para desarrollo de aplicaciones web para moviles
ZK es el nombre del framework, ¿pero representa la sigla de algo?
jeje que buena pregunta la del ultimo anonimo, y la verdad hasta ahora no he dado con la respuesta.
Lo unico que se es que la empresa detras de ZK es Potix
Tal vez ZK signifique: Zero Knowledge o Zuper King!! xD o depronto Zing Kong, o tal vez Zeta Ka! muahah la verdad eso quedara como un misterio
En principio pensé que podía ser "Zero Kode", pero "Zero Kode" es una herramienta de diseño visual basada en Web para ZK - http://www.zkoss.org/smalltalks/zerokode1/zerokode1.dsp
Zi Kiero, framework de mon amuggg!! :D
anonimo: jmarranz quiero hacerte la siguiente pregunta para obtener un mejor rendimiento es mejor usar framework céntrico en el servidor o en el cliente ?
Uff, que pregunta. La respuesta en mi opinión no es nada nada sencilla.
Para simplificar el análisis considera un juego hecho a base de tecnologías web con mucha interactividad, por ejemplo éste. Es un ejemplo extremo en donde el código (JavaScript) del juego puede cargarse al principio y el renderizado (que en este caso es básicamente movimiento de imágenes) se hace en JavaScript inmediatamente después de cada pulsación.
El otro extremo está por ejemplo el "auto-suggest" del buscador de Google, es indudable que Google necesita consultar el servidor para buscar qué palabras son las más populares de acuerdo con las letras que has puesto, por tres razones:
1) Es inviable cargar toda la base de datos de Google en el navegador.
2) La lógica de búsqueda/selección de palabras se ejecuta mucho más rápido en el servidor (Java/C++/.Net, paralelismo, cachés etc) que en el cliente (JavaScript). Dicho código puede ser bastante grande.
3) Google no creo que tenga intención de publicar los criterios por los que decide que una palabra es más popular que otra. Es decir el código no se envía al cliente por criterios "de privacidad corporativa".
Faltaría analizar el código que añade visualmente las palabras sugeridas a la lista que sale debajo de la caja de texto. Dicho código tiene dos opciones:
1) El código está en el cliente (JavaScript) y se encarga de generar el HTML adecuado con las palabras que recibe del servidor.
2) El código está en servidor y se genera el HTML adecuado y un poquito de JavaScript necesario para insertar dicho HTML en el sitio adecuado.
En el caso 1) el auto-suggest a pesar de ser claramente una aplicación "centrica en el servidor" respecto a los datos y "la lógica de negocio" sería una aplicación "céntrica en el cliente" respecto a la visualización. En el caso 2) la aplicación sería claramente "céntrica en el servidor" en todos los aspectos.
¿Cual tendría más rendimiento? Depende.
En el servidor el renderizado HTML lo haría a la velocidad de la luz pues se hace con todo el poder de las tecnologías del servidor y de la computación a escala, en el cliente se hace en JavaScript que todavía es bastante lento y con las limitaciones del entorno web y si han de soportarse muchos navegadores el código JavaScript es más grande y torpe aún, el precio de la complejidad en el servidor (por ejemplo en Java) es mucho menos. En mi opinión en este caso gana el enfoque céntrico en el servidor en rendimiento.
Ahora bien, en el primer caso el servidor está haciendo una tarea, el renderizado, que podría hacer el cliente, si el servidor está muy sobrecargado esa tarea extra puede volverse en su contra pues "un listo (servidor) saturado de trabajo puede ser más lento que un torpe (navegador) ocioso". Otro inconveniente del renderizado en el servidor, es que el servidor conoce el estado de visualización en el cliente y por tanto consume más memoria en el servidor.
anonimo: y si alguno de la comunidad conoce de un framework que cumpla con las espectativas para desarrollo de aplicaciones web para moviles
Después de meses y meses, al leer esta pregunta te dan ganas de cortarte las venas o pintártelas de verde.
En el caso del auto-suggest de Google no hay renderizado en el servidor porque es un caso de aplicación sin estado en el servidor.
Esa es una de las razones por las que por ejemplo el auto-suggest no funciona en las BlackBerrys tal y como Storm y Bold (excepciones cada dos por tres), pues el navegador de la BlackBerry necesitaría un código JavaScript más a medida o que se resolvieran sus peculiaridades en el servidor generando el HTML adecuado y el JavaScript necesario para insertarlo, mucho más fácil hacer esto en el servidor que en el cliente.
¿Cual tendría más rendimiento? Depende.
En el servidor el renderizado HTML lo haría a la velocidad de la luz pues se hace con todo el poder de las tecnologías del servidor y de la computación a escala, en el cliente se hace en JavaScript que todavía es bastante lento y con las limitaciones del entorno web y si han de soportarse muchos navegadores el código JavaScript es más grande y torpe aún, el precio de la complejidad en el servidor (por ejemplo en Java) es mucho menos. En mi opinión en este caso gana el enfoque céntrico en el servidor en rendimiento.
Yo creo que aun depende más. Si el servidor tarda 1 microsegundo en calcularlo y el cliente tarda 10 millisegundos... ¿cual te da mejor rendimiento cara al cliente? Ninguno o ambos, ya que para el cliente será lo mismo por qué no lo puede apreciar, aunque uno tarde 10.000 veces más que el otro.
Es más, si el HTML que has de generar es "complicadillo", puede que sea más eficiente enviar sólo los datos que el HTML, ya que el retardo de red añadido de enviar el marcado HTML puede que se coma la ventaja de calcularlo en el servidor.
Eso sí, si has de soportar clientes heterogéneos nada mejor que tenerlo todo controladito en el servidor y usar el cliente como terminal "atontao", que se les da muy bien.
greeneyed: ya que el retardo de red añadido de enviar el marcado HTML puede que se coma la ventaja de calcularlo en el servidor
Tienes mucha razón, pero ese HTML complicadillo en una solución céntrica en el cliente no está mágicamente ya en el cliente, ha sido cargado o bien como un trozo de HTML que se carga al mismo tiempo que el framework o bien embebido en código JavaScript.
El problema en el caso de la solución céntrica en el cliente es que normalmente se carga en tiempo de inicialización pues la carga bajo demanda de código es un tema complicado pues es casi inevitable que se haga de forma asíncrona, por eso suelen tardar tanto en cargarse las aplicaciones ricas hechas con frameworks cliente porque básicamente se suele cargar "la aplicación" al inicio.
En una solución céntrica en el servidor si no pasas por una parte de la aplicación "dicha parte" no se carga y es mucho más fácil cargar código JavaScript bajo demanda, en mi caso cada vez más tiendo a inyectar JavaScript desde el servidor bajo demanda y no cargarlo inicialmente pues la casuística de los navegadores me obliga a tener cada vez más código JavaScript específico de un navegador que otros no utilizan.
Totalmente de acuerdo. Si no sabes en principio que código vas a necesitar, es más eficiente cargarlo cuando ya lo sabes, pero tampoco hay que mitificar demasiado lo de la carga "on demand" por que a veces tener algunas cosas pre-cargadas es mucho mejor. Eso sí, tampoco es cuestión de cargarlo todo de primeras. Como bien dices es una de las paradojas de algunas aplicaciones ricas, se venden como algo "más rápido y eficiente" y la primera impresión es que tardan "siglos" en cargarse la primera vez.
Es una cuestión de no caer en una optimización prematura y tomar las decisiones con los datos en la mano y con una postura abierta.
hola estoy realizando una aplicacion en Eclopce Zk, no tengo mucha esperiencia, puesto que apenas lo estoy investigando.
Nada mas que se me ha dificultado la crear un for, ya que me marca error declararlo de manera normal, por ejemplo en el for marca error cuando le pongo los signos > o <, Espero que me puedan ayudar...
Gracias
ZK signfica "Zero Kode" referente a que el framework no requiere escribir codigo en java script para la instrumentación de clientes Ajax, aun que no lo prohibe, es posible desarrollar aplicaciones usando scripts propios del framework, pero por misma recomendacion de los desarrolladores de zk se obtiene mejor desempeño si dejamos todo el manejo de eventos del lado del servidor. Yo empece a usar el zk desde sus primeras versiones y definitavamente es de los mejores frameworks para desarrollar aplicaciones web con ajax. !Saludos desde México!
Mario Zúñiga Trejo
mzuniga@mcsistema.com.mx
ZK Rules!!!
Escribe tu comentario