Frameworks Web basados en componentes del lado del servidor: El reto del cache del lado del cliente

Digamos que se tiene un pantalla mas o menos así:

Tengo un combobox (<select/>) en donde selecciono el país, y abajo se rellena otro combobox, en donde aparecen los estados para ese país, y cuando selecciono un estado, me aparecen las ciudades de ese estado, y cuando selecciono la ciudad, me aparecen otro combo para seleccionar la colonia.

Hacer algo asi con Richfaces+JSF, con Tapestry, AribaWeb o Wicket no parece demasiado difícil...
Hacer lo mismo con Capucchino+DWR, o Flex+GraniteDS, tampoco es demasiado difícil...

Pero aquí viene el reto: Reducir el numero de peticiones al servidor pero sin traerme todos los datos de todos los países/estados/ciudades/colonias desde un principio, por que eso hará que mi pantalla tarde demasiado en cargar (y desperdicie memoria), pero quiero que al seleccionar un país por segunda vez, no vuelva a ir por la lista de estados... y al seleccionar un estado por segunda vez, no vuelva a ir por la lista de ciudades al servidor, y al... bueno, ya se hacen una idea.... ;-)

Este tipo de optimizacion de rendimiento puede parecer innecesaria para la típica aplicación web en la que un usuario rara vez utiliza una forma de captura mas de una vez (pantalla de registro), pero para aplicaciones empresariales, tener la capacidad de cachear los refrescados de pantalla puede hacer una gran importancia en cuanto a rendimiento (y la percepción del rendimiento) que experimentaran tus usuarios y tus jefes. Si un usuario va a estar capturando datos en la misma pantalla todo el día tal ves tenga que "jugar" con comboboxes encadenados unas 100 o 200 veces con un secuencia de comboboxes similar (o con alguna otra secuencia de refrescado susceptible de ser cacheada en controles de árbol, o de selección de pestañas). El posible que el usuario (o tu jefe) acepten que la primera ves que se sigue un determinado camino "de refrescado" se tarde en traer los datos "por que es la primera ves", pero, por que habría de tardarse las otras 199 veces?. Es importante hacer notar que para estos casos el cache de Hibernate no ayuda casi en nada por que al final de cuentas, ese cache esta para ayudar al servidor de aplicaciones a ahorrarse viajes a la base de datos y no para ayudar a la navegador a ahorrarse viajes al servidor de aplicaciones.

¿Que tan fácil es hacer esto con los frameworks AJAX disponibles hoy en día? Ciertamente lo he podido hacer usando DWR, Seam Web Remoting o GraniteDS, pero en esos casos, he tenido que programar la interfaz en JavaScript (o ActionScript en el caso de Granite y Flex). ¿Que pasa con los frameworks que creen que se puede describir el comportamiento de una pantalla usando "server side components" (como JSF, AribaWeb, Wicket o Tapestry)? Son estos frameworks "server side centric" una mala elección si se quiere un comportamiento de este tipo? (es de plano imposible conseguir este comportamiento) o simplemente no ha habido nadie interesando en permitir este tipo de comportamiento de "cache en el cliente definido mediante componentes de servidor"?

Puede tu framework hacer esto? JSF+Richfaces no puede, al menos no en su encarnación actual (3.x) . Pero ya propuse un mecanismo que quiza podría hacerlo posible. Desgraciadamente mi conocimiento de Richfaces no llega al grado de poder implementarlo yo mismo (o siquiera poder estar seguro de que sea implementable) Creen ustedes que llegue a ser posible en JSF 2.0/Richfaces 4.x? AribaWeb no puede hacerlo... no he probado con Wicket o con Tapestry, pero no he podido encontrar un ejemplo que muestre que es posible....
Saben ustedes de un framework basado en componentes definidos en el servidor que ya tenga una característica así? un mecanismo general para cachear "refrescados" de pantalla sin necesidad de escribir código en Javascript? Me encantaría conocer uno...

Comentarios

Opciones de visualización de comentarios

Seleccione la forma que prefiera para mostrar los comentarios y haga clic en «Guardar las opciones» para activar los cambios.
Imagen de ecamacho

Cache HTTP

Creo que la solución más simple en este caso es usar los mecanismos para cache de HTTP: respuestas 304, headers de expiración y etags. En esta presentación Nacho Coloma habla de cómo funcionan y su framework web Loom (http://loom.extrema-sistemas.org/) los usa por si quieres mirarte cómo lo implementó: http://www.slideshare.net/icoloma/caching-web-contents-in-the-browser-99...

Al final no es la solución más óptima porque siempre habrá un roundtrip al servidor (aunque con un payload muy pequeño ya que solo viajarán headers) pero es una forma más natural que construir algo del lado del cliente y te evitas estar construyendo algo para cada nueva tecnología que usas en el cliente.

Imagen de luxspes

Cache HTTP: Interesante, no lo conocia

Creo que la solución más simple en este caso es usar los mecanismos para cache de HTTP: respuestas 304, headers de expiración y etags.

Interesante solución esta de la respuesta 304, no la conocía... Si bien no es tan eficiente como guardar el manualmente en el cliente el resultado de la ultima peticion, ciertamente puede tener un impacto visible en el rendimiento... me pregunto porque AribaWeb o Richfaces no aprovechan esta posibilidad... supongo que es hora de preguntar en sus foros de discusion...

Imagen de daynatem

MM

La verdad no entendi cual era tu problema.

Creo que te paso lo mismo que a muchos, complican los problemas que son sencillos.

Tal vez te ayude este artículo.

http://bit.ly/9jz1HF
http://bit.ly/8XkEhF
http://bit.ly/aKTCsR

Imagen de luxspes

MM: client side cache?

La verdad no entendi cual era tu problema.

No te preocupes, a veces pasa.

Creo que te paso lo mismo que a muchos, complican los problemas que son sencillos.

En cierto sentido, captaste una parte importante de la esencia de mi problema: "complicar lo sencillo". Mantener un cache en el cliente (web browser) de las peticiones hechas al servidor deberia ser sencillo, pero (en mi experiencia) los frameworks de componentes "del lado del servidor" generalmente olvidan implementar mecanismos para que eso sea posible (complicando asi, algo que deberia ser sencillo)

Tal vez te ayude este artículo.

Gracias, se ve interesante... tal vez me sirva, le voy a dar una leida... aunque en una primer vistazo superficial, no parece relacionado con la falta de soporte para "client side caches" en frameworks de componentes de servidor

Imagen de ezamudio

Vaadin

Ya has revisado Vaadin? Es un framework basado en GWT, no escribes nada de Javascript, se ve bastante poderoso, no sé si haga lo que necesitas, yo lo estoy revisando, a ver si luego escribo algo en mi blog.

Y por que no con AJAX?

Quizá no entendí tampoco yo tu problema, pero

Por que no usas AJAX+Javascript AJAX?

No entendí cual es el problema con ellos, para eso son, para ser usados en el cliente, cual de estas dos es:

1.O será que no quieres que nunca más en la vida se vuelvan a pedir los datos ( aunque se apaque la máquina, se caiga la red o se vaya de vacaciones el capturista ) y que cuando regrese esten ahi luego luego?

Para esto puedes usar HTML5 que la mayoría de los browser modernos soporta ( lease no ie6 )

2.O , si se trata de que una persona esté trabaje y trabaje en la misma pantalla todo el día y solo hacer las peticiones mínimas ( en este caso.. 4, pais, estado, ciudad, colonia )

En este caso muy poco de javascript usar AJAX es más que suficiente.

@Daynatem: Ejecutar javascript del lado del servidor

Ejecutar javascript del lado del servidor no ayuda en nada y quizá solo agregue complejidad a la solución.

Imagen de fcodiaz

por que en JS no?..

Bueno este es un tema que me llamo la antención mas que nada por que JavaScript es uno de mis lenguajes favoritos y por desgracia el menos reconocido por todo los desarrollladores, no se por que se sigue haciendo menos.. al inicio se desvaloraba por que era para paginas de internet.. las paginas de internet no pasaban de ser revista, JS era para validar un form o poner una marquesina en el title de tu pagina y solo para eso.. porcos se aventuraban a modificar el dom para hacer animaciones y poco se siguen atreviendo..

Diganme ¿por que pasa esto..?? es FLOJERA de aprender un nuevo lenguaje... no creen en JS.. o que?.... muchos dicen que JS es difícil pero yo he profundizado en el y pues la verdad no se trata de un ensamblador y no se me hace nada dicil nada de otro mundo eso si tienes que dominar muy bien los conceptos web (HTML,CSS) que por lo que veo también les da flojera aprender, no veo por que resistirse a aprender y a hacer algo en JS además que la potencia de JS esta comprobada por las aplicaciones de Google y de infinidad de aplicaciones web que hoy dia tenemos en internet.. en lo personal yo si le he entrado hoy día tengo muy buen nivel.. y no solo estoy hablando de validar un formulario o de copiar algo en JQuery y hacer un $("element").show(). si no estoy hablando de realizar prototipos(clases en JS) generar herramientas que me faciliten el post desarrollo, en estos días estoy tratando de ver la posibilidad de implementar MVC de lado cliente.. si!... MVC en JS.. y creanme que se puede...! y solo lo estoy perfeccionarlo para empresa dar a conocer mis idea esta idea era la que tenia pensada plasmar en mi tesis para obtener el grado de ingeniero.. que aparte no soy el primero que lo intenta(http://javascriptmvc.com), digamos mi idea es un modelo doble MVC.. tal vez sea un poco mas trabajo y exija un poco mas de conocimiento, pero es mas ahoro de código, mas divisiones de capas para la división del trabajo en equipos de trabajo de 1 capa la cual quieren fusionar la mayoría de los frameworks actuales la capa cliente y la capa servidor, en cada una un MVC que se comunican entre si mediante XHR... a este modelo se me ocure llamarlo SC2MVC(Server Cliente 2 MVC) inspirado mucho en mi experiencia desarrollando tanto en cliente como en servidor. no es nada nuevo simplemente es regresar al inicio dividir lo que por ende esta separado, el beneficio que creo es mas valioso es que al programar de esta forma nuestra GUI tiene independencia total del lado servidor... al solo manejra JS en el cliente modiicar el dom en el cliente y enviar y obtener datos al servidor(obviamente en el servidor tenemos que revalidar) me deja libre de saber que es lo que pasa en el servidor, que si es PHP o Java o .net o lo que sea... al programador de la interface no le interesa... el recibe texto plano, JSON o XML.. esto hace que nuestra interfaces sea portable tanto en el cliente como en el servidor, para el servidor solo tendríamos que reescribir las operaciones que ser realizan en este lado.. y la capa cliente queda intacta.. así es facil migrar de una aplicación PHP a Java o a .net si la tecnología de lado servidor no nos favorece.

por lo cul puedo tener un desarrollador en JS que se despreocupe del servidor, tener un Diseñador grafico que me maneje CSS, y un practicante de una tecnica que me pueda generar HTML's y un master en Java que me genere el lado servidor si preocuparse del diseño de las hojas de estilo y bla bla bla... y el alma de todo esto es JS y su objeto XHR

Creo que el desarrollo de aplicaciones de lado servidor se esta yendo por un rumbo que no debería la lucha de los frameworks actuales es quien se lleva el cliente al servidor, una idea que no creo que se etan tratando de unir dos capas que por ende son separadas, estamos pidiendo una leguaje que nos permita crear otra aplicación es como querer un lenguaje de programación para hacer programas que hagan programas y es mas o menos lo que tenemos unos con mayor exito otros con menos.. pero si nos vamos por el lado de las herramientas actuales siempre tendremos una dependencia a proyectos de terceros, por eso no me gusta usar frameworks y eso no quiere decir que siempre este reahaciendo las cosas lo digo por que luego luego salta el que dice que por no usar un framework ya soy toto por que rehago las acosas 1000 veces.. y se equivocan se crear funciones se crear clases.. se crear mis herramientas!...

bueno solo los invito a que profundicen en el maravilloso lenguaje que es JS. en cuanto a tu problema, creo que es un problema trivial si se puede hacer, puedes tener una estructura de datos que se valla llenando conforme a peticiones.. consulto una ciudad la ciudad se carga en el cliente y se queda en la estructura para la posible futura petición. pero si se tiene que programar en JS o bueno hoy no se si algún framework lo permita.. por lo generar las cosas automatizadas genera un montón de bodigo de mas que se un buen programador haría en tres lineas así que no creo que si existe algún framewor optimice la aplicación como un programador decente lo aria, tal ves tu ocupas dos lineas pero el framework ejecutara 10 lineas de su código y te generará 20. por eso no me gustan las herramientas que automatizan algunas cosas. pero bueno ahora si que es razón de gusto, pero ingeniero soy y me gusta crear cosas :P no un técnico que solo le dicen como hacer las cosas y sigue la receta al pie.....

y @OscarRyz caes un un par de barbarismo un poco crueles :P... uno
AJAX es JavaScript, es como si hubieras dicho por que no lo haces con JavaScript+JavaScript, ajax es una implementación del objeto XHRde JS que nos permite hacer peticiones a un servidor Http, y que en teoria y para llamarle AJAX deveriamos de recibir un XML como respuesta a esa petición. después de recibirla realizamos lo que queramos en JS. es como convinar httpClient y Java y le ponemos AJHC ,, :P me cansan los acrónimos :P.

y otra cosa que te equivocas. HTML5 aun no hay un explorador que lo soporte al 100% ni IE9 ni 8 ni 7 y menos el 6..Firefox, Chrome y Safari lo soportan a medias con implementaciones propias.. ya que el HTML5 todavía esta en Revición es del 2009 y aun no se a actualizado el borrador oficial http://dev.w3.org/html5/html-author/ últimamente se ha hablando mucho de el no dudo que so API de conexión a BD no llegue a servir, pero un producto estable y comercial dudo que en estos días sea posible tal ves de aqui a unos 8 o 10 años mas ejemplo CSS3 http://www.w3.org/TR/2000/WD-css3-roadmap-20000414 su ultimo BORRADOR es del 2001 y no hay una versión definitiva y apenas los exploradores empezaron a implementar y eso excluyendo al IE que por desgracia es donde están nuestros clientes y donde nos dirán mira en mi compu no se ve..¿por que?... ¬¬... bueno esperemos que ese sea un cambio rápido...

Imagen de fcodiaz

Decepcionado de Deitel & Deitel

Deitel & Deitel 7ma Edicion

jeje este libro yo lo tengo... y en el al inicio en el apartado de web2.0 el autor dice las aplicaciones AJAX son dificiles... mmmmm cuando lei eso me dieron ganas de tirar el libro y me arrepentí de comprarlo :P, solo por decir que esto es dificil... el autor perdio mi respeto y eso que escribio un mega libro muy completo de Java.. pero si queremos hacer algo y aprender algo.. creo que es mala idea iniciar con esa metalidad.. de "es dificil"

@FcoDíaz - No, no tanto.

...@OscarRyz caes un un par de barbarismo un poco crueles :P...

Je je así parece pero NO! no tiene nada de bárbaro lo que escribí, quizá son imprecisiones solamente.

Ajax+Javascript No, no, no, no no. No es como decir javascript + javascript, es más bien como decir.... mmhhh que analogía será buena: Java + JDBC, es decir, el lenguaje + una "parte" de ese lenguaje ( aunque el JDBC no es una parte de Java sino una biblioteca.. en fin ) O sí, ( ahora que estoy releyendo tu post ) es como usar Java + HttpClient y decír, Java + HttpClient es como decir Java + Java :)

En todo caso debí decir: Javascript + Ajax, eso sí, pero no es una barbaridad, solamente una imprecisión.

HTML 5

No quizé dar entender que lo soporte al 100% ( para que diablos se necesitaría video aquí? ) A lo que me refería es a la parte relevante que es el almacenamiento fuera de linea ( web storage ) ya funciona para Chrome Safari IE8 y FF. ¿Usan implementaciones propias? Pues sí pero no creo que haya limitante para customizar dependiendo del browser no?

En todo caso debí decir: Puedes usar webstorage definido aun en draft para el HTML con las implementaciones propias de webstorage para Google Chrome 4.xxxx, Firefox 3.6+, Microsoft Internet Explorer 8

De cualquier forma, para los combos dependientes de post, usar JavaScript + AJAX ( O, Javascritpt con llamadas al "Application Programmer Interface" del "eXtensible Markup Language Hyper Text Transfer Protocol Request , o para corto al API del XMLHTTPRequest, o para los cuates AJAX ) es más que suficiente.

Saludos

Imagen de ezamudio

Problema original

Tal vez no leyeron completo el post de luxspes o no captaron el problema. En resumen, su inquietud es que el soporte de AJAX que dan los frameworks actuales para desarrollo web en Java, es algo limitado. El ejemplo lo dice todo. El problema es sencillo: Seleccionas país en un combo y te muestra estados en otro combo. Los datos del segundo combo dependen de lo que se seleccione en el primero. Es muy fácil implementarlo con Javascript a mano o incluso con un framework que genere el javascript automáticamente y no lo tengamos que teclear; a fin de cuentas es una función que se activa cuando cambia la selección del combo y lo que hace es con AJAX pedir al server los datos del segundo combo para la selección hecha en el primer combo.

Lo anterior lo hacen todos los frameworks y es muy fácil de implementar incluso de manera directa con Javascript. Lo que luxspes dice que ya no se puede hacer más que directamente con Javascript, es que esos datos del segundo combo que dependen del primero, solamente se deberían pedir una vez al server. Si seleccionas México, traerse la lista de estados de México solamente la primera vez y guardarlos ya en el cliente, al menos durante la sesión; si seleccionan USA entonces traers sus 50 estados y guardarlos; si el usuario selecciona nuevamente México, ya no debería haber otra petición al server, porque ya se pidieron una vez y realmente no es nada complejo tener una especie de cache en el cliente y saber que si ya se trajeron los datos entonces no hay que volver a ir por ellos. Pero eso ninguno de los frameworks que tienen ya esa funcionalidad en AJAX lo implementa; todas esas funciones predefinidas van al server siempre, aunque ya se hayan pedido esos datos antes, dentro de la misma sesión y todo.

Y ahí es cuando ya pierde el encanto el framework, porque en su lista de monerías siempre dice "ya no tienes que usar Javascript, ofrecemos funcionalidad AJAX por medio de [jQuery|Prototype|Scriptaculous|loquesea] de modo que puedes hacer varias cosas de AJAX sin tener que teclear una sola línea de Javascript", pero resulta que sólo es para lo más básico. Oh desilusión.

Y aquí viene un poco para todos:
- Luxspes, eso que anuncian todos los frameworks, es muy básico y sólo lo dicen como las características principales y más atractivas del framework; ya que te adentras en el que sea, todos van a decir que para cosas más complejas, puedes meter tu propio javascript. Igual que puedes hacer tus propios componentes y tus propias clases porque a fin de cuentas, el framework es para simplificarte mucha talacha pero de todas maneras tienes que programar.

- Oscar: A mi también me sacó de onda lo de AJAX + Javascript... si la J de AJAX es Javascript, pero luego entendí que te refieres a alguna librería de AJAX ya hecha, no tener que implementarlo usando el XHR a patín.

- fcodiaz: No sé dónde trabajes, tal vez andas de freelance, o en una empresa donde eres el único programador, pero el uso de frameworks tiene muchas ventajas, incluso para programadores solitarios:

  • Cuando tu proyecto consiste en modificar una aplicación existente, si conoces los frameworks usados para crear dicha app, ya te ahorraste mucho tiempo (de hecho por lo general es requisito conocer lo que se usó para una app existente, para poder recibir el proyecto en esos casos)
  • Estás usando herramientas que mucha gente usa, que varios conocen, que varios han reportado defectos, que han sido corregidos, que salen nuevas versiones con correcciones, etc. Si haces tus propias herramientas, eres el único que las conoce y no sabes qué defectos puedan tener hasta que ocurren problemas en aplicaciones existentes.
  • Al trabajar con otras personas, en un equipo, el uso de uno o varios frameworks va a causar que las cosas se hagan de cierta forma y por lo tanto ya no depende una parte de una aplicación de un solo programador sino que otro podría terminar su trabajo en caso que por la razón que sea alguien salga del equipo.
  • Los clientes que tienen cierta idea de tecnologías pueden pedirte la lista de frameworks que vas a usar, para verificar si les gusta... por qué les va a gustar un framework y otro no? por el soporte que tenga, por la cantidad de gente que los utiliza, etc; si les dices "yo no creo en los frameworks, tengo mis propias herramientas" algunos te dirán "ok no me importa hazme mi sistema y ya" pero otros te dirán "no gracias, no quiero depender de ti para siempre porque el sistema que me hagas, nadie más lo va a querer tocar porque no conocen tus frameworks, no sabemos qué licencia tienen, si alguien más los puede modificar, y van a terminar reescribiendo la aplicación el día que la quiera cambiar"
  • Si tienes tus propias herramientas y las usas para trabajos por encargo (como todos nosotros a fin de cuentas), cuando entregas un sistema hecho y te piden el código fuente, debes entregar el fuente de tus librerías. Con qué licencia entregas eso? Si no especificas que ese código ya lo tenías hecho tú y que realmente es propiedad tuya y les estás dando una licencia de uso, entonces el cliente puede ir al INDAUTOR y registrar toda la obra como suya, y ya se quedó con la autoría de tus componentes.
  • Finalmente, si nadie más que tú conoce tu propio framework, el día que alguien tenga que modificar algo hecho por ti, tendrá que revisar tooooodo tu framework para saber qué hace y conocerlo. Y al final puede decirle al cliente, "esta cosa no sé ni cómo la hicieron y estoy perdiendo mucho tiempo en tratar de entenderle; y si mejor lo reescribo usando x, y, z frameworks?" o bien cobrarle un ojo de la cara por todo el tiempo que le tome entenderle a tus componentes, pero a fin de cuentas es tiempo perdido porque muy probablemente no los vuelva a ver.
  • Si estás trabajando en una empresa y todos esos componentes que usas a diario, hechos por ti mismo, los hiciste en esa empresa, en la oficina, en horas de trabajo, como parte de un proyecto, etc, entonces ni siquiera son tuyos, son de la empresa. El día que te vayas de ahí esos componentes se quedan y no tienes permiso de usarlos, no te los puedes llevar, a menos que llegues a un arreglo con la empresa. Y ahí hablo por experiencia. Si en cambio los hiciste en tu propio tiempo, entonces si estás trabajando en una empresa, debes dejarles MUY claro que esos componentes son tuyos; registra tu código en INDAUTOR. Y si está tan fregón podrías publicarlo como software libre, súbelo a SourceForge, ponle ASL o LGPL o la licencia que más te guste, documéntalo y promociónalo. Así es como algunos programadores han logrado que sus propios componentes y frameworks que hicieron porque ninguno les convence, se vuelva popular y otras personas lo utilicen, quitando así todos los problemas que acabo de mencionar.
Imagen de fcodiaz

me caen mal los acronimos

@OscarRyz pues.. yo digo que si.. por que es decir el todo mas una de sus parte.. seria mas correcto solo decir AJAX, ya que en que en el acronimo se describe la participación de JavaScript y en base es JavaScript solo que la técnica se hiso popular con ese nombre y se llevo a confusiones de creer ser una nueva tecnología(que de nuevo no tiene nada), por eso creo que no es correcto decir javascript+AJAX el primero ya esta implícito en el segundo,

aunque al final prácticamente nadie hace AJAX(Asynchronous JavaScript And XML) hacen AJAH (Asynchronous JavaScript And HTML) o AJAJ(Asynchronous Javascript And JSON) o PAJAJ(PHP Asynchronous Javascript and JSON) que es lo mismo que el anterior pero especificando que es PHP en el lado servidor.. ahora entonces también podremos tener JAJAJ(JAVA Asynchronous Javascript and JSON) ó AxAJAJ(ASPx Asynchronous Javascript and JSON) o AAJAJ(ASP Asynchronous Javascript and JSON)... etc etc. etc..

y todos absolutamente TODOS son la misma cosa ¬¬ el vil uso de XHRy de desvalorado JavaScript que consulta un server HTTP sin importar que hay detrás del texto plano que recibirá y luego JavaScirpt lo procesa y muestra por eso honor a quien honor merece yo en lugar de usar todos esos burdos acronimos para referirme a que tengo que hacer un "AJAX" prefiero decir maneja XHR... y que es eso un objeto de JavaScript... para que nos hacemos bolas con tanto acronimo.. ya parecemos televisoras copiándose programas y modificando poquito el nombre...

que bonito era cuando decías voy aprender C, Java, JavaScript, PHP, C++, C#, ASP... etc... ahora tenemos mil frameworks y mil acronimos, por que simplemente no aprender bien el lenguaje y ser disciplinado (orden, convenciones, estructura, reciclaje... etc).. pero bueno.......!

Imagen de fcodiaz

@ezamudio de acuerdo ;)....

Oks.. de hecho mi plan es publicar todas las ideas que tengo.. en mi blog personal voy publicando librerías que voy haciendo, y los post de Reflexión de Java van encaminado a ello.. digamos al final el ejemplo practico de Reflexión es el núcleo de un framework que utilizo regularmente (aunque en su versión PHP) no he tenido la fortuna de tener un proyecto formal en Java :(... pero si un motón en PHP y siempre enfocando la programación a ser un sistema y no solo una paginas web, en si estoy migrando mi forma de trabajo a Java ya que me gusta mucho el orden que he logrado, css, javascript, imagenes, etc donde deven de ir todos trabajando juntos pero no revueltos, módulos representados por clases para acoplar a otro proyecto solo tengo que copiar y pegar la clase con 0 configuraciones.. ya lo había intentado hacer para un proyecto en la universidad pero no le entendí muy bien a los de Reflexión(no me salia la ejecución de métodos). así que termine haciendo decisiones con IF's por que se me vino la fecha de entrega xP,
yo quiero un framework no que me ayude a no hacer cosas pero si a organizar y lo que ya tengo hecho sea fácil de integrar con lo nuevo, que pueda separar la programación del diseño eso es lo que busco y lo que hasta cierto punto he logrado =D y sobre todo mucha libertad al programar.. por eso quiero mostrar como hago mi framework y no solo liberar el código y decir hay ta! para quien lo quiera modificar(si es que le entienden), si no guiar desde su construcción para que quien quiera ver como funciona lo pueda entender. pues igual haber que pasa tal vez me luego me deje llevar por la corriente y me ponga a "frameworciar".. ya le tuve que entrar a jQuery xP... y eso que no le quería entrar pero requerimientos son requerimientos y ps el jefe dijo.. ps ya q!....

Problema original ---> Problema de diseño¿?

creo que es algo que puedes construir independientemente del framework (como ya mencionan, usando el mismo javascript o facilidades del framework o librería ajax que estes usando). No es algo que debe estar 'incluido' pues la idea de AJAX es precisamente las peticiones asíncronas. Creo que es mas bien un problema de 'patrón de diseño' que uno como desarrollador pudiera requerir implementar; lo podrías resolver de varias formas programáticamente.

Otra cosa que se debe tomar en cuenta es que si lo que quieres es mejorar el tiempo de respuesta al usuario, y digamos por ejemplo que para no estar iendo al servidor cada vez por los datos de los combos, tendrías traerlos de un golpe, así que la 1a. vez traerías muchos datos que no ocuparías y de todas formas tardarías en obtenerlos.

De nuevo, es una cuestión de diseño y de 'qué tanto es tantito?', usar paginación, usar javascript manteniendo un hidden con datos precargados/solicitados anteriormente, otros mecanismos...etc

Saludos.

RE: Decepcionado de Deitel & Deitel

Para mi ese es un libro muy bueno. Además que eso de AJAX más bien se refiere a: "Para mí es difícil" ó "A mí no me gusta AJAX", ¿y a quién no le ha pasado?; recuerdo cómo mis amigos de la preparatoria batallaban con Física, Cálculo y Química, a lo que ellos decían: "La física es lo más difícil que he visto" y yo me quedaba pensando: "¿Difícil, física?"...En cambio yo batallaba mucho con materias cómo Biología, Administración, etc. y yo le decía que para mí era difícil la administración y la biología y ellos me decían: "Pero si tu le entiendes a física a la primera...".

Otra cosa es que muchas veces no diferenciamos no gustar de no saber, secundado de: hay cosas que uno escribe para sí mismo otras son para la gente, creo que quién escribió eso lo escribió para él.

No creo que haya temas fáciles o difíciles, sólo diferentes; cómo las personas, creo que habrá mucha gente cómo tu que diga: "Hombre, que una aplicación AJAX la dejas lista en 2 semanas", mientras habrá otros que digamos: "Entre menos JS mejor.", la forma en la que vemos las cosas es subjetiva.

Redundando y para que quede todo bien claro, lo que para ti es oro para mi no. No creo que porqué a alguien se le haga difícil Java lo tenga cómo mal programador, capaz y el me da un buen repaso en implementación de patrones y yo lo critico sólo porqué el considera que Java es difícil [por el hecho de qué no le gusta Java].

Imagen de JaimeItlzc

Deitel & Deitel

Te voy a decir la experiencia con ese libro que por cierto es demi novia, ami me parece un libro tan bien como mal por que contiene ejemplos aveces un tanto drasticos que si vas iniciando con java ni les entiendes, por que me ha pasado que compañeros tienen ese libro pero pues no le entienden por que algunos ejemplos dicen "ser muy avanzados" y la verdad si aveces vienes ejemplos un tanto complicados de entender.

Ami parecer si quieres comenzar a leer ese libro tienes que tener un poquito de conocimientos previos ya en java.

Saludos.

RE: me caen mal los acronimos

+1

Considero que debería ser: "Quiero aprender [inserte lenguaje aquí] en su versión [escritorio, web, móvil]" Sin más, tener una estable base de donde echar mano. Ahora cómo bien dices muchas personas se aburren de Java porqué ya no es sólo Java ahora son millares de frameworks diciendo que son la neta y al final de cuentas te das cuenta que de ese millar muchos hacen las cosas de la misma manera sólo que [inserte aquí característica] es mejor (y por lo general no son cosas de peso). Y seguido de aprender el framework tienes que hacer que convivan en armonía con una frágil configuración (aunque eso de las annotations está haciendo algo al respecto).

Aunque si nos ponemos minuciosos, ya esto se está saliendo; antes yo recuerdo que si tu aprendías PHP, era sólo eso, ahora en cambio tienes: Cake, Akelos y muchos más que puedes ver por acá...Si vas a Perl verás algo similar, si vas a Python verás algo similar, incluso ASP tiene ya varios frameworks

Por desgracias a veces las cosas no cambian para bien en nuestro punto de vista, pero igual es interesante este mundillo de la web.

Reviviendo el tema, ¿luxspes

Reviviendo el tema, ¿luxspes no trataste con cookies?...Aunque el modelo de los frameworks que has mencionado es stateful, las cookies funcionan más para stateless, sin embargo considero puede ser una solución quizás no óptima pero si momentánea, mientras encuentras la definitiva.

Imagen de luxspes

the three great virtues of a programmer

Pues ecamacho fue el unico que me hablo de una solucion apararentemente viable... y la verdad no he tenido tiempo de verificar por que ningun framework de componentes del lado del servidor la usa....

ezamudio (no me sorprende) fue el que capto mejor la escencia del problema que describo aqui, aunque sus conclusiones fueron un tanto obvias:

- Luxspes, eso que anuncian todos los frameworks, es muy básico y sólo lo dicen como las características principales y más atractivas del framework; ya que te adentras en el que sea, todos van a decir que para cosas más complejas, puedes meter tu propio javascript. Igual que puedes hacer tus propios componentes y tus propias clases porque a fin de cuentas, el framework es para simplificarte mucha talacha pero de todas maneras tienes que programar.

Si, lo se, pero no deja de fastidiarme que me vendan que son la octava maravilla desde la invención del pan de caja y no puedan lidiar con esto.

- Oscar: A mi también me sacó de onda lo de AJAX + Javascript... si la J de AJAX es Javascript, pero luego entendí que te refieres a alguna librería de AJAX ya hecha, no tener que implementarlo usando el XHR a patín.

AJAX + Javascript efectivamente es redundante

- fcodiaz: No sé dónde trabajes, tal vez andas de freelance, o en una empresa donde eres el único programador, pero el uso de frameworks tiene muchas ventajas, incluso para programadores solitarios:

Definitivamente el uso de frameworks tiene muchas ventajas, incluso para programadores solitarios, es por eso (y mi ciega pasion por la primera virtud de la programacion ;-)) que quisiera encontrarme un framework que me ayudara con este problema. Esto no me ha llevado a desechar los frameworks, solo ha hecho que me concentre en utilizar y recomendaro solo aquellos que me ayudan a tener estos beneficios (como jQuery del lado del cliente) y Springframework 3.0 del lado del server, que me da ETags (que son mejor que nada, pero no tan buenos como un verdadero mecanismo semi-transparente de cache del lado del cliente)

Imagen de luxspes

ineficientes: soluciones basadas basadas en el servidor

Reviviendo el tema, ¿luxspes no trataste con cookies?...Aunque el modelo de los frameworks que has mencionado es stateful, las cookies funcionan más para stateless, sin embargo considero puede ser una solución quizás no óptima pero si momentánea, mientras encuentras la definitiva.

No estoy seguro de como quisieras que usara las cookies para resolver el problema, pero supongo que seria de un modo similar a las ETags. De cualquier modo, al final, queda de manifiesto que cualquier metodo (ETags, cookies) que requiera de comunicarse con el servidor sera inferior a cualquier metodo que lo haga con un cache en el cliente. Razon por la cual siempre sera ineficiente definir la UI de una RIA usando un frameworks web basados en componentes del lado del servidor. Aunque por supuesto, la eficiencia no lo es todo.

Imagen de luxspes

problema trivial: Uno no puede hacerlo todo

en cuanto a tu problema, creo que es un problema trivial si se puede hacer, puedes tener una estructura de datos que se valla llenando
conforme a peticiones..

Dejenme ser claro, no es que piense que este sea un problema particularmente dificil... al contrario, pienso que tan facil que un framework de ultima generacion basado en componentes del lado del servidor, como JSF 2.x o Tapestry 5.x o AribaWeb o.... deberian poder resolverlo... sin embargo no es asi, eso me genera una disonancia cognitiva... o no es tan facil, o los creadores de todos esos frameworks estan ciegos o de plano son mensos.... (antes de que digan algo, ninguna de esas 3 teorias me late... para mi es sencillamente un misterio por que no ayudan en nada para resolver este problema, supongo que estan ocupados con problemas mas "importantes" como ponerles "temas de diferentes colores" o agarrarse a trancazos en las reuniones del JCP :'-( )

consulto una ciudad la ciudad se carga en el cliente y se queda en la estructura para la posible futura petición. pero si se tiene que programar en JS o bueno hoy no se si algún framework lo permita.. por lo generar las cosas automatizadas genera un montón de bodigo de mas

El caso de los componentes Richfaces de JSF.

que se un buen programador haría en tres lineas así que no creo que si existe algún framewor optimice la aplicación como un programador decente lo aria,

De hecho, efectivamente, no existe, la pregunta es, para este caso en particular,: por que no existe?

tal ves tu ocupas dos lineas pero el framework ejecutara 10 lineas de su código y te generará 20.

De nuevo, el caso de los componentes Richfaces de JSF.

por eso no me gustan las herramientas que automatizan algunas cosas.

Bueno, aqui si te vas al extremo (dudo que en tu casa tengas letrina en ves de WC, estufa de leña y acarres el agua del pozo mas cercano a tu casa (a 5 o 10 kilometros) todos los dias ;-) ) . Y bueno, supongo que mantienes tu computadora encendida conectada a un dinamo en una bicicleta estatica sobre la que andas mientras escribes... (aja, si como no)

pero bueno ahora si que es razón de gusto, pero ingeniero soy y me gusta crear cosas :P no un técnico que solo le dicen como hacer las cosas y sigue la receta al pie.....

Supongo que también vives a la intemperie en lo que construyes tu casa... y tambien apuesto a que construiste la compu con la que estas tecleando.... supongo que tallaste a mano cada tecla... y ciertamente tienes una fabrica de chips ahi a la intemperie contigo (tambien construida por ti) ;-) (si... seguramente...)

Todos necesitamos de todos, y no podemos inventar todo nuevo, ni negarnos a usar una herramienta "hasta que lo resuelva todo". Sin embargo, es mi opinion que los frameworks de componentes basados en el servidor, al menos para la parte que corresponde a la UI, sencillamente van de salida, por que sencillamente no pueden competir con cosas como jQuery.

Supongo que es por eso que ya no me interesa tanto lo que pase mas alla de los JSP.... al final, JSF, Tapestry y Ariba terminaran por morir en las manos de HTML5, jQuery y otros frameworks de su tipo.

Imagen de ezamudio

YUI

Oye y has visto si YUI trae algo para lo que necesitas? Porque como que estás buscando la solución en los frameworks del lado del server, cuando esta bronca es del lado del cliente... jQuery, Prototype, YUI, etc pueden hacer lo que buscas...

Imagen de Jvan

Que hay de GWT?

Razon por la cual siempre sera ineficiente definir la UI de una RIA usando un frameworks web basados en componentes del lado del servidor.

Que hay de Google Web Toolkit que supuestamente todo lo haces del lado del servidor y te olvidas de Javascript, según yo gmail y wave de google estan hechos bajo está tecnología y no dejan nada que desear en cuanto a rendimiento y dinamismo.

Imagen de luxspes

Oye y has visto si YUI trae

Oye y has visto si YUI trae algo para lo que necesitas? Porque como que estás buscando la solución en los frameworks del lado del server, cuando esta bronca es del lado del cliente... jQuery, Prototype, YUI, etc pueden hacer lo que buscas...

Ciertamente con cualquiera de ellos se puede... pero no se si alguno ya traiga esta funcionalidad de forma natural. De cualquier modo final llegamos a la misma conclusion, los frameworks de componentes UI del lado del servidor están condenados a morir, ya sea por su ineficiencia intrinseca, ya sea por la falta de imaginacion de sus inventores.

Memcached

¿Y de casualidad no intentaste hacerlo con memcached?...En teoría es tener los objetos en memoria, bastaría con en lugar de ir a checar al servidor, pues revisar en memoria si los tienes y retornarlos en caso de tenerlos y según yo (o sea ni siquiera en teoría =p) te ayudaría a con los demás clientes (no sólo con uno). De esa manera te ahorrarías la vuelta que te tienes que dar al server y el paginado.

Imagen de ezamudio

No es opción

Lo que luxspes quiere es que una vez que el navegador obtuvo datos para el combo hijo cuando el combo padre está en opción 1, ya se queden en la memoria del navegador (una vil variable en javascript, un mapita o algo, no es difícil pero ningún framework lo hace así por default). Así cuando selecciones las opción 2 del combo padre, y luego selecciones nuevamente la opción 1, ya no se haga una petición al server, porque ya previamente se habían obtenido los datos para la opción 1.

Tampoco se trata de guardarlos en cache permanente ni usar cookies ni nada de eso. Estamos en el entendido de que al cambiar de página se pierde esa info, no hay problema. Pero estando en la misma página, realmente no hay razón para que cada vez que se selecciona una opción en el combo padre, se tenga que hacer una petición al server para obtener las peticiones del combo hijo, de manera repetida. Debería haber máximo una petición por cada opción del combo padre.

Es cuestión de que el método de javascript que se invoca al seleccionar la opción del combo padre, busque primero en un mapa accesible a nivel página (o al menos para esa función), si ya se tienen los datos para esa opción. Si ya se tienen, se usan. Si no se tienen, se piden al server, se almacenan en memoria y se usan.

memcached requiere forzosamente petición al server, desde el navegador. No es opción.

Re: No es opción

Pero a lo que me refiero es que sería en teoría más rápido que ir al servidor de ahí a la base de datos y de ahí de regreso...Es decir, quizás lo puedes ver en desempeño, aunque dudo que sea igual que con JS...Sin embargo no lo veo una labor difícil con JS (un JSON) aunque tampoco conozco las limitantes de alguno de los frameworks que usan y probablemente haya que meterse directamente con el framework.