He publicado la versión 0.7.0.1 de ItsNat (corrige un bug importante de la v0.7).
Esta versión introduce muchas novedades las más importantes son las siguientes:
* El motor W3C DOM Xerces ha sido substituido por la implementación de Batik (no incluido SVG) debido a que Xerces tiene problemas de hilos muy importantes no existentes en Batik. Batik DOM ha sido extendido para soportar X/HTML y para proveer a ItsNat de un nivel de transparencia mayor siguiendo la filosofía "The Browser Is The Server". Por ejemplo ahora el código Java ((EventTarget)element).addEventListener("click",listener,false) registra un listener de eventos DOM REMOTO, es decir, es como si se hubiera ejecutado esta sentencia en JavaScript en el cliente.
* Se ha mejorado el soporte de XHTML, de hecho a nivel de DOM servidor HTML y XHTML son lo mismo (al serializar al cliente es cuando se hace de la forma adecuada) y el soporte DOM de otros espacios de nombres no X/HTML (SVG, XUL, MathML...).
* Ahora SVG es un namespace de primera clase más aún. Además del soporte de SVG puro en navegadores con SVG nativo, se ha añadido dicho soporte con plugins (útil sobre todo para Internet Explorer): Adobe SVG Viewer (v3 and v6), Renesis 1.1, Savarese Ssrc, SVGWeb y Batik como applet. Savarese Ssrc proporciona además XUL a MSIE.
* Soporte de SVG (o cualquier otro namespace no X/HTML) embebido dentro de XHTML servido con MIME text/html en navegadores con SVG nativo. En MSIE y MIME text/html código SVG puede ser embebido dentro de XHTML usando SVGWeb y Adobe SVG Viewer incluso con cambios dinámicos de DOM, muy útil en aplicaciones Single Page Interface (es decir sin navegación). La manipulación DOM de SVG embebido en X/HTML con Adobe SVG Viewer (ASV) es una característica UNICA de ItsNat gracias al descubrimiento casual de una funcionalidad oculta del ASV. El soporte de SVGWeb es interesante porque gracias a que la programación se hace en el servidor, se solucionan de forma transparente algunos problemas y limitaciones que tiene SVGWeb, de tal manera que la programación de SVG embebido en X/HTML es idéntica para navegadores con SVG nativo y con SVGWeb.
* Más navegadores soportados tal y como Bolt, UCWEB, Motorola Symphony, Opera Mobile 9.7 y 10, BlackBerry JDE 5.0 (Storm 2 y otros), Palm OS etc. Se mejorado muchísimo el rendimiento y la estabilidad en Pocket IE (WinMob 6.0 and 6.1) hasta el punto de que ahora la mayor parte de los ejemplos del Feature Showcase ¡funcionan!
* Soporte de XUL incluyendo AJAX en navegadores con motor Gecko (FireFox y otros) y en MSIE gracias al plugin Savarese Ssrc.
* Soporte parcial de Google App Engine (GAE) incluyendo AJAX. ItsNat es junto con Vaadin y ZK apenas los tres únicos frameworks céntricos en el servidor que funcionan en GAE. Demo (ver "Google App Engine working examples"): http://itsnatfeatshow.appspot.com
* Los archivos JavaScript del framework ya no son públicos (se cargan desde ItsNat.jar) por lo que ahora la instalación de ItsNat es simplemente añadir los .jar requeridos.
* Se ha mejorado la técnica de creación/filtrado de componentes. Gracias a las mejoras es posible hacer funcionar el Feature Showcase en Pocket IE o Motorola Symphony introduciendo "al vuelo" en el DOM los cambios necesarios sin "bastardizar" la aplicación web para estos navegadores.
* Auto-enlazado en el servidor de los documentos hijo cargados a través de los tags iframe, object, embed o applet (Batik SVG). Desde el documento padre puede accederse a los documentos hijo y viceversa pudiendo usar iframe/object/embed/applet en aplicaciones Single Page Interface.
* Más novedades, resolución de bugs, nuevas APIs, algunas APIS cambiadas etc.
Lista completa:
http://itsnat.sourceforge.net/php/download/RELEASE_NOTES.html
Web del Proyecto: http://www.itsnat.org
Demo Online: http://www.innowhere.com:8080/itsnat/
Demo en GAE: http://itsnatfeatshow.appspot.com
Demo ItsNat Experiments: http://www.innowhere.com:8080/inexperiments/
Etiquetas: j2ee, itsnat, batik, adobesvgviewer, svgweb, googleappengine
José María, deberías aprender de Sun. La calidad, la robustez y la funcionalidad de un producto son siempre secundarias al marketing que se emplea para promocionarlo. Esta debería ser la versión 7.0 de isNat, y no la 0.7. Pero bueno, después de tantas discusiones sobre este tema creo que no yo no te voy a convencer... Así que voy a pedir ayuda.
Queridos usuarios del portal ¿consideráis que a la hora de decidir si merece la pena invertir parte de vuestro tiempo en evaluar un nuevo producto va a influir el hecho de que el producto sea una versión "0.5" o una versión "5.0"? ¿Asumís que si algo no ha llegado a 1.0 todavía no está listo para producción? Y ¿preferís usar versiones "2.X" y "3.X" a "1.X" porque considerais que cuando un producto ya lleva varias versiones estables es indicio de que realmente va a continuar su desarrollo y no se va a discontinuar el año que viene?
Ya Abraham, es un tema del que ya hemos hablado, en privado sobretodo, el problema es que yo intento tener un profundo respeto al programador (aunque no siempre se lo merece), y eso me lleva ser EXCESIVAMENTE prudente, si miras el RELEASE NOTES de la 0.7 verás apartados como los siguientes:
- Changed names
- Moved methods
- Removed methods
Afortunadamente los "Changed names" son meros cambios sistemáticos de nombres y los métodos movidos y removidos son muy escasos, es un signo de que LA API CADA VEZ ES MAS Y MAS ESTABLE. ¡ES LA API Y NO LOS BUGS! lo que me motiva a mantener ItsNat en 0.X.
Yo no hago ItsNat para gente sin criterio, un programador con criterio SABE que una versión 7.0 puede ser una basura y que una versión 7.1 puede obligar a hacer cambios profundos en tu programa. Lo hemos visto en Java con 1.5 (lo de Java 5 es puro marketing), es curioso pero de 1.3 a 1.4 la compatibilidad es prácticamente total hacia adelante y hacia atrás, pero un programa en 1.4 PUEDE NO COMPILAR en modo 1.5 (eso le pasaba a ItsNat anteriormente por "culpa" de Xerces) y hacia atrás ni te cuento. Por no hablar de JSF 1.2 respecto a JSF 1.1
Se puede ver algo parecido en el proyecto Atmosphere, que va por la 0.5, no se si algún día meteré Atmosphere dentro de ItsNat (para tener la opción de Comet asíncrono) pero no me echará para atrás en absoluto el 0.5, porque para mi ese 0.5 significa "estoy dándole la vuelta al web y no se donde me va a llevar".
Esto mismo no me ha impedido obviar el soporte de SVGWeb, cuya estado es todavía ¡¡ALPHA!!, pero ya quisiera una tecnología alpha hacer cosas como ésta o éstas (abrir con el Internet Explorer)
De todas las maneras la v1.0 está más cerca que nunca.
José María, ¿te has planteado alguna vez hacer algún tipo de taller introductorio sobre IsNat? del estilo de los que montan en escuela de groov.
Tu propuesta siempre me ha parecido interesante, pero nunca encuentro tiempo para evaluarla de verdad. Una clase magistral siempre es más didáctica que la lectura de un manual.
Sobre las versiones.... en mi caso no me dejo llevar por la numeración. El 80% de los casos es puro marketing. Hay muchas betas más estables que muchas versiones 3.0 :)
Me estoy planteando más bien un Webcast con Skype y dispositivas, pues después de ver el escasito nivel de asistencia que tuvo el último OpenJavaDay que hizo Sun en Madrid no se hasta que punto merece la pena un acto presencial.
De todas formas ItsNat es TERRIBLEMENTE sencillo en nivel más básico, si conoces JavaScript y conoces el W3C DOM conoces lo más fundamental de ItsNat, lo demás son construcciones encima. Es decir, si entiendes lo que hace este ejemplo ya sabes un montón de ItsNat.
Y si conoces Swing ya sabes prácticamente manejar la gran mayoría de los componentes de ItsNat, los cuales por otra parte no son ni siquiera imprescindibles, se puede hacer lo mismo a mano con las características básicas (pues de hecho están construidos "encima" del nivel Core). El manual tiene 250 páginas porque está lleno hasta aburrir de ejemplos de código Java y HTML. El mismo Feature Showcase es la suma de montones de mini tutoriales online.
Saludos,
Primeramente, debo dar ánimos a "jmarranz" por su por su perseverancia en el proyecto "itsnat", y agradecerle como siempre la gran calidad de sus intervenciones en Java Hispano.
Hay un conjunto enorme de elementos en el ecosistema de Java. En mi caso, me resulta muy difícil evaluar un gran número de frameworks que hay hoy en día y que evolucionan a gran velocidad.
Cuando entramos en el mundo Web, la cosa ya se complica para pasar elementos entre los clientes y servidores, controlar el estado, ....
Aprovechando que ha salido la nueva version de "itsnat", PLANTEO las siguientes preguntas:
1.- ¿Respecto a componentes, puedo utilizar componentes de otros frameworks como RichFaces, controles Google Maps, etc? ¿De donde puedo sacar mas componentes?
2.- ¿Puedo utilizar persistencia tipo JPA, de forma natural?
3.- ¿Puedo generarme controles y eventos dinámicamente? Es decir, ¿podría crear un controlador que me permita generar una pantalla a partir de un objeto (por ejemplo crear una pantalla para mantener clientes, a partir de la definión del POJO de clientes)? ¿Como afectaría esto al rendimiento? (Esta idea es clave en frameworks como OpenXava)
4.- La inclusión de JavaScript, ¿puede dar problemas de pérdida del control de los hilos de ejecución a los programadores novatos? ¿Existen procedimientos para el control de esos hilos?
5.- ¿Existe una comunidad de usuarios potente para resolver dudas y plantear mejoras?
6.- ¿Es fácil de utilizar este framework?
7.- Respecto a otros frameworks, ¿Que ventajas aporta? ¿O cual es su nicho ecológico?
8.- ¿Se puede integrar con certificados electrónicos para restringir accesos, cifrar la información, y firmar documentos? ¿Es facilmente adaptable a los criterios establecidos en los últimos reales decretos de Seguridad y interoperatividad en el "marrón" de la administración electrónica?
9.- ¿Como se comporta en proyectos de gestión con muchas tablas (contabilidad pública, nóminas, impuestos y tasas, seguimiento de espedientes)? ¿Y con proyectos formados por un equipo de gente?
10.-¿Se pueden definir flujos (Work Flow) de manera natural?
11.- ¿Como se comporta ante elevadas cargas de trabajo?
12.- ¿Existen muchas aplicaciones "complejas" o "extensas" desarrolladas con este framework?
No se si estoy desviándome de lo que se plantea en esta noticia. Pero los que esteis trabajando con este framework, creo que sería muy positivo que comenteis vuestra experiencia.
Eduard
Joer tavernes la de trabajo que me das :)
Hay un conjunto enorme de elementos en el ecosistema de Java. En mi caso, me resulta muy difícil evaluar un gran número de frameworks que hay hoy en día y que evolucionan a gran velocidad.
Aparentemente, si tienes algunos criterios claros al final quedan muy muy pocos, y cuando digo criterios no me refiero a buenos/malos me refiero a "que bien pero esto no es lo que quiero".
Solamente con decidir si quieres un framework céntrico en el cliente o en el servidor ya has reducido a lo bestia las opciones, y si tu elección es que sea intensivo en AJAX y no esté orientado a páginas, reduces más aún las opciones y si quieres soporte de montones de navegadore pues más aún y si quieres tener varias opciones para SVG ...
1.- ¿Respecto a componentes, puedo utilizar componentes de otros frameworks como RichFaces, controles Google Maps, etc? ¿De donde puedo sacar mas componentes?
Si te refieres a reutilizar en plan drag and drop componentes JSF pues no. Si te refieres a utilizar una gran gama de componentes precocinados llenos de colorines la respuesta es no. Ahora bien ten en cuenta que en la mayoría de frameworks el desarrollo de componentes a medida es un infierno, es decir fuera de lo que hay ya hecho no suele haber salvación (estoy pensando en JSF).
En ItsNat aunque existe el concepto de componentes que se pueden hacer a medida registrables etc cualquier simple grupo de nodos es un componente PER SE: cualquiera de sus elementos puede emitir eventos y puedes manipular la visualización del mismo como te de la gana.
¿Qué eres un mal diseñador web para los colorines? pues piratea el trabajo de otros y listo.
¿Que necesitas algunas chorraditas visuales de cambios de color o movimiento? pues usas JavaScript a medida o jQuery o el framework JS que más te guste (sabiendo lo que haces claro).
Respecto a Google Maps, te recuerdo que es realmente una tecnología JavaScript, los frameworks JavaScript si se usan con cuidado pueden llevarse muy bien con ItsNat, pueden convivir (cada uno con su parte de la página) e incluso colaborar, por ejemplo el Syntax Highligther que se usa en el Feature Showcase está gestionado desde el servidor.
2.- ¿Puedo utilizar persistencia tipo JPA, de forma natural?
La que te de la gana, ItsNat es totalmente agnóstico. Ahora bien si te refieres a que el motor de persistencia está unido hasta el tuétano con el motor web (que es lo que es ItsNat), pues no, y eso de "natural nada", está bien para desarrollo rápido con los inconvenientes que tiene el desarrollo rápido.
3.- ¿Puedo generarme controles y eventos dinámicamente? Es decir, ¿podría crear un controlador que me permita generar una pantalla a partir de un objeto (por ejemplo crear una pantalla para mantener clientes, a partir de la definión del POJO de clientes)? ¿Como afectaría esto al rendimiento? (Esta idea es clave en frameworks como OpenXava)
Si te refieres a la generación automática de la visualización a partir de POJOs tipo OpenXava pues no. Lo cual no quita que una capa encima de ItsNat hiciera esas cosas. OpenXava está en el otro extremo en filosofía de gestión de la visualización, por eso nos llevamos tan bien Javier Paniza y yo porque ItsNat y OpenXava no se solapan prácticamente nada.
4.- La inclusión de JavaScript, ¿puede dar problemas de pérdida del control de los hilos de ejecución a los programadores novatos? ¿Existen procedimientos para el control de esos hilos?
No se a qué te refieres pero como consuelo te diré que ItsNat en su nivel "Core" es básicamente programación JavaScript pero en el servidor con Java, pero el mismo tipo de código. En teoría NO necesitas JavaScript con ItsNat. Pero como te decía antes ItsNat se lleva muy bien con el JavaScript, de hecho las repuesta a un evento AJAX es JavaScript y el programador puede enviar código JavaScript a medida al cliente como respuesta a cualquier evento AJAX.
5.- ¿Existe una comunidad de usuarios potente para resolver dudas y plantear mejoras?
Para ser sincero no.
6.- ¿Es fácil de utilizar este framework?
Echa un vistazo al tutorial que citaba más arriba y luego piensa como harías la estupidez que hace dicho tutorial con tu framework AJAX preferido céntrico en el servidor por ejemplo JSF.
7.- Respecto a otros frameworks, ¿Que ventajas aporta? ¿O cual es su nicho ecológico?
Esto daría para mucho más de rollo, pero resumiendo, ItsNat es para aquellos que están hartos de que el framework les diga como tiene que ser su aplicación y tenerse que romperse la cabeza para cambiar cualquier estupidez hecha por defecto. ItsNat es una paleta de colores no un puzzle con el dibujo ya hecho, es un lienzo en blanco no un "pinta y colorea" con el dibujo ya hecho, es material de construcción no una casa prefabricada.
8.- ¿Se puede integrar con certificados electrónicos para restringir accesos, cifrar la información, y firmar documentos? ¿Es facilmente adaptable a los criterios establecidos en los últimos reales decretos de Seguridad y interoperatividad en el "marrón" de la administración electrónica?
La verdad es que no tengo mucha idea de los criterios de la Administración española aunque algo he trabajado con ella hace años, pero lo más probable que si quieres meter AJAX te dirán que de detergentes nada, me refiero a que suele ser criterios muy conservadores. Ahora bien si hay AJAX por medio ItsNat es quizás el framework AJAX servidor más transparente, flexible y controlable que existe (a la hora de evaluar la seguridad etc).
Respecto a lo de los certificados electrónicos mi impresión es que lo que estás pensando es totalmente ortogonal (ajeno) a lo que estamos hablando.
9.- ¿Como se comporta en proyectos de gestión con muchas tablas (contabilidad pública, nóminas, impuestos y tasas, seguimiento de espedientes)?
Pues te diré por ejemplo que ItsNat en el cliente no usa getElementById sino un sistema de cacheado de nodos que te encontrará el nodo que quieres modificar en miles de líneas mucho más rápido que un getElementById o igual de rápido si el navegador usa algun tipo de cacheado, con la ventaja de que ItsNat no te obliga a que tus filas tengan ids, el atributo id está libre en ItsNat.
¿Y con proyectos formados por un equipo de gente?
ItsNat separa a lo bestia el trabajo del diseñador web y el programador Java, puesto que los templates son puro HTML, sin custom tags ni bindings ni guarrerías de esas.
10.-¿Se pueden definir flujos (Work Flow) de manera natural?
No se a qué te refieres con "natural", pero ItsNat apuesta por eliminar la navegación por páginas por lo que adios a los form, adios a los problemas del back/forward, adiós a los problemas del reload, adios a recargar todo para cada click. El tipo de programación es más bien el de una aplicación de escritorio, en web se tiende a llamar Single Page Interface.
11.- ¿Como se comporta ante elevadas cargas de trabajo?
En ItsNat hay un exquisito cuidado en que los bloqueos de hilos (sincronizaciones) entre usuarios sea prácticamente nulo. Teniendo en cuenta que no hay reloads, al servidor devuelve exactamente lo que ha de cambiar en el cliente lo que reduce a lo bestia el tráfico y el trabajo de renderizado.
12.- ¿Existen muchas aplicaciones "complejas" o "extensas" desarrolladas con este framework?
Están las mias (algunas cosas que hace el Feature Showcase te aseguro que no las verás en ninguna parte como el visor/control remoto y el uso de SVG) y alguien de Sri Lanka está haciendo una red social sobre turismo con ItsNat (y jQuery).
Si alguien quiere convertir su vieja web/aplicación en una aplicación Single Page Interface puede contactar conmigo. Cuanto más antigua y menos JavaScript más sencillo.
No necesitaría el código fuente, sólo el acceso a la web y a las páginas que se quieren convertir.
El resultado, si no hay barreras técnicas que sólo pudieran resolverse con acceso al código fuente, sería un prototipo hecho en Java e ItsNat con simulación de acceso a base de datos, con la misma funcionalidad (simulada obviamente) y estética pero:
* Sin los problemas de reloads, back, forward etc
* Ejecutable en montones de navegadores móviles con AJAX.
* Enorme reducción del ancho de banda usado
* Gran reducción del tiempo de proceso y consultas a la base de datos al no tener que regenerarse páginas completas.
* Mayor productividad.
* La capacidad de indexación como "páginas" por Google no tiene por qué perderse, y con el uso de links especiales ("permalinks") pueden usarse para bookmarks.
* Y como "bonus": visor remoto del uso de la aplicación de otros usuarios (el control remoto completo es también posible).
Deberías hacer caso a Abraham, todas mis respuestas a sus preguntas avalan lo que dice.
@jmarranz ¿Cómo de sencillo es pasar de una aplicacion de escritorio Swing a ItsNat? Yo estoy ya desfasado del mundo web pero queria actualizar un proyecto personal a este entorno. Además como veo que el modelo SPI me gusta más que el de navegación al uso, me parece que encajaría bien.
Jose María, he probado la aplicación en GAE y algunos links funcionan, pero otros no.
Por otro lado, estoy de acuerdo con Abraham. 1.0 es cuando consideras que los demás pueden utilizarlo, por debajo de eso yo considero que no tengo derecho a protestar por un cambio del API. A partir de ahí puedes aplicar marketing.
supertrasgu: Deberías hacer caso a Abraham, todas mis respuestas a sus preguntas avalan lo que dice.
No se donde están "todas tus respuestas" yo creo que se te ha olvidado enviar el comentario, el "enviar" es más de un paso, a mi también me ha pasado.
Anónimo: ¿Cómo de sencillo es pasar de una aplicacion de escritorio Swing a ItsNat? Yo estoy ya desfasado del mundo web pero queria actualizar un proyecto personal a este entorno. Además como veo que el modelo SPI me gusta más que el de navegación al uso, me parece que encajaría bien.
Pues yo creo que te sentirías muy agusto, obviamente tienes que cambiar el chip respecto a APIs (Java W3C DOM) y respecto a visualización (HTML), pero no respecto al modelo de programación que es tipo escritorio (evento-modificaciones visuales correspondientes). Yo no digo que no se puedan usar páginas en ItsNat, lo que defiendo es que si quieres puedes evitarlas...totalmente.
Swing como bien sabes está basado en componentes, en ItsNat son opcionales pero existen y la mayoría son imitación de Swing y de hecho usan algunos de sus button models, data models, selection listeners y parcialmente su sistema de edicion "in-place", por lo que tienes ya muchas cosas aprendidas.
Ahora bien, no esperes un clon de Swing, los componentes ItsNat se "vinculan" con trozos de HTML a modo de patrón, es decir no son prediseñados visualmente como ocurre en Swing, la ventaja es que te da libertad de diseño visual lo cual en mi opinión es impagable en el entorno web. Gracias a eso el ListModel de Swing se usa tanto para gestionar un HTML select como para los elementos de una columna de una tabla, una lista de LIs o en general cualquier lista de tags bajo un tag común.
Echa un vistazo a los ejemplos que usan elementos de Swing, lo interesante es que pulses la solapa "Source Code", te paso al menos tres links (hay más ejemplos):
icoloma: Jose María, he probado la aplicación en GAE y algunos links funcionan, pero otros no.
GAE tiene algunas limitaciones importantes, una de las gordas es que Swing está prohibido, incluso las clases inocentes que yo uso. Se que dentro de un tiempo harán un filtro más fino (por lo menos reconocen que la queja es razonable).
El problema del Feature Showcase es que usa Swing en el tree de los ejemplos por lo que no funciona en GAE, podría quitarlo usar un element tree y con un poco más trabajo hacer lo mismo, pero mi objetivo es mostrar que ItsNat funciona (parcialmente) en GAE, no conseguir que el Feature Showcase que es una demo general funcione en GAE. No verás tampoco demos generales corriendo en GAE de ZK o Vaadin que son los únicos frameworks tipo servidor junto a ItsNat corriendo en GAE.
Hay ejemplos del Feature Showcase que por varias razones se cargan desde iframe y no usan Swing, esos son los que puedes ejecutar, los que están debajo de "Google App Engine working examples". Yo tengo mis propios tests en GAE y te aseguro que la mayoría de los ejemplos del nivel Core funcionan en GAE.
Respecto al 1.0 bien vale, será pronto, pero mi opinión es que los programadores deberían ser alérgicos al marketing tontorrón de los números.
obviamente tienes que cambiar el chip respecto a APIs (Java W3C DOM) y respecto a visualización (HTML), pero no respecto al modelo de programación que es tipo escritorio (evento-modificaciones visuales correspondientes)
Sin olvidar que estamos hablando de comparar programación local (habitualmente) con programación distribuida. Ese ligero detalle se suele pasar por alto y es uno de los cambios filosóficos gordos. No es problema de ItsNat si no de pasar de programar en escritorio a web, pero eso de que "es lo mismo" es un cuento de hadas al que la gente se apunta con esperanza y luego pasa lo que pasa. :).
Respecto al tema de las versiones. Es comprensible que si hay cambios en el API no te decidas por pasar a la version 1.0 y que quieras enfocar tu mercado a programadores con criterio... si estás dispuesto a que tu mercado sean cuatro gatos pelaos :). De todas formas, tardar muucho en llegar a una version estable es síntoma de "featuritis" y da poca confianza. Precisamente los programadores con criterio saben que ese tipo de proyectos son peligrosos y hay que esperar a ver si se estabilizan o donde acaban. Así que si "ahuyentas" a un tipo de desarrolladores por el numero de versión y a otros por la falta de estabilildad... ¿quien te queda?
Pragmáticamente, para tener éxito hay que apuntar al mercado más gordo y "sacar algo". Un producto maravilloso con un mercado enano o sin vender no da beneficios.
greeneyed:Pragmáticamente, para tener éxito hay que apuntar al mercado más gordo y "sacar algo". Un producto maravilloso con un mercado enano o sin vender no da beneficios.
Suponiendo que un 10% por ciento del mercado web Java esté formado por programadores con criterio, que necesitan un framework al estilo de ItsNat (el creer que un framework web vale para todo el mundo es creer en una gran mentira) y que han visto que durante ese tiempo la filosofía del framework se ha mantenido, que los cambios del API han sido coherentes y cuyo impacto ha sido siempre pequeño pues fundamentalmente se contruye sobre hombros de gigantes es decir W3C DOM, y Swing)... para mi ese posible 10% es INMEEEEEENSO.
El 90% restante no me importa que se lo quede Oracle, bueno un poquito también para otros :)
porque creo que lo pequeño es hermoso.
greeneyed: Precisamente los programadores con criterio saben que ese tipo de proyectos son peligrosos y hay que esperar a ver si se estabilizan o donde acaban
Por ahora al menos ItsNat ha sobrevido a proyectos respaldados por multinacionales lease por ejemplo Woodstock. El software más estable es el software muerto, ahora Woodstock sin duda es muy estable...
Por otra parte siempre es posible esperar a que algún día se estabilice el propio estándar JSF :b
La supervivencia de ItsNat depende casi exclusivamente del respaldo que tenga por parte de sus usuarios no de su número de versión.
Suponiendo que el 90% de los programadores Java lo hacen para web y que son mas de 6.000.000, me alegra saber que ItsNat tiene mas de 540.000 usuarios :). Ahora en serio, un 10% de programadores con criterio me parece bastante generoso, que encima tengan poder de decisión para escoger framework... aun menos, y que apuesten por algo "inestable" menos aun...
La supervivencia de ItsNat depende casi exclusivamente del respaldo que tenga por parte de sus usuarios no de su número de versión.
No es que le deseemos mal a ItsNat, pero es que el respaldo de los usuarios depende en bastante medida del "número de versión", sobretodo si implica que todavía hay cambios incompatibles.
Y lo siento, pero deducir que como hay software con versiones estables que no ha triunfado, entonces no es necesario tener versiones estables para triunfar no sobrevive al más mínimo examen lógico :).
Y sobrevivir a proyectos respaldados por multinacionales no es tan difícil, el mío ha sobrevido a cualquier framework MVC existente en Java pero eso no significa que lo vaya a usar automáticamente la gente, incluso con versiones estables (ahora para servlet 3.0 he empezado las versiones 4.x). Si alguien con criterio lo quiere usar en una empresa, si le dices que a cada versión puede haber cambios incompatibles que le harán volver sobre el código ya existente o quedarse sin la resolución de errores o mejoras... si lo usa entonces es que en realidad no tiene criterio.
De todas formas, cada uno es libre de llevar sus proyectos como quiera, simplemente es mi opinión personal que un API congelado de vez en cuando es sintoma de buena salud y para indicar eso se suelen usar los numeros de versión.
En un mundo como el actual, los productos dirigidos a "una élite" están condenados a acabar en un nicho y desaparecer.
Todo esto suponiendo que la idea es que lo use alguien más que uno mismo y "sus cuatro amigos", si no es el caso, como si no hubiera dicho nada :).
greeneyed: Y lo siento, pero deducir que como hay software con versiones estables que no ha triunfado, entonces no es necesario tener versiones estables para triunfar no sobrevive al más mínimo examen lógico :).
¿Insinuas que JSF el estándar de la industria es estable? por no hablar de la interoperabilidad de las implementaciones...
greeneyed: si le dices que a cada versión puede haber cambios incompatibles que le harán volver sobre el código ya existente o quedarse sin la resolución de errores o mejoras... si lo usa entonces es que en realidad no tiene criterio.
Umm ¿estás hablando de JSF? ¿de EJB? ¿del paso de Java 1.4 a 1.5?
greenyed: quedarse sin la resolución de errores o mejoras...
Eso se resuelve muy sencillamente con un contrato de soporte (los errores), evidentemente nadie con criterio pretenderá que "by the face" le solucionen los fallos de un producto superado/cambiado/evolucionado en versiones posteriores o que las mejoras de versiones superiores se retro-apliquen en versiones inferiores, no conozco ese tipo de software.
Como nos encanta hablar de tonterias y criticar lo anecdotico, como si una version 20 asegurara algo cuando encima algunos productos te pasan de la version 1 a la 5 con todo el morro, lo que sea en vez de valorar si es bueno o no, si resuelve algun problema que no resuelven otros, si funciona bien o mal, si es sencillo o dificil, si es apropiado para unas cosas mejor que otras, si tiene un gran futuro y merece la pena que siga ahi mejorando o seria mejor enterrarlo, el hilo es deprimente compadezco al autor de ItsNat, no se lo merece.
¿Insinuas que JSF el estándar de la industria es estable? por no hablar de la interoperabilidad de las implementaciones...
Lo es en cuanto a que tiene una versión con un API estable, que si sacan la 5.2.1 sabes que tus aplicaciones para las 5.2.0 han de funcionar salvo error u omision. Por supuesto que si sacan la 6.0.0 no existe esa garantía, pero es que en cuanto a estable nos referimos a tener un API que durante un par de versiones no cambie y eso esté "medianamente garantizado" y para eso se usa normalmente la numeración.
Eso se resuelve muy sencillamente con un contrato de soporteNadie "en su sano juicio" se tiraría a usar en producción un producto que en cada versión puede traer cambios incompatibles por que eso significa que si una versión tiene un bug y quiero la solución que viene en la siguiente versión, tendré además que retocar el código que ya funcionaba por los cambios del API incompatibles. Con contrato de soporte o sin el, por que como bien dices, nadie vendrá a rehacer mi código.
Eso lo puede hacer uno en sus proyectos de experimentación, pero en la mayoría de casos en producción es una insensatez por que el mantenimiento se te come por los piés a no ser que sólo tengás una aplicación, y no muy grande.
Y si a lo que te refieres es que necesitas un contrato de soporte para darle mejoras sobre una version estable a un usuario, pues sigue habiendo versiones "mayores" sin cambios de API. Que te las den gratis o pagando no tiene nada que ver.
Umm ¿estás hablando de JSF? ¿de EJB? ¿del paso de Java 1.4 a 1.5?
No, estoy hablando de Java 1.4 a 1.4.1, de esta a 1.4.2 etc. Si Java sólo fuera saltando de versión grande en versión grande, no la usaría ni la mitad de gente, siendo muy generoso, y si encima en cada cambio ocurriesen cambios incompatibles hacia atras, básicamente ninguna empresa lo usaría. Los cambios incompatibles hacia atras en Java han sido introducidos con cuentagotas y básicamente han sido por cuestiones de nuevas palabras reservadas.
Y vaya, ya se nota que le tienes tirria a JSF, en eso coincidimos, pero de su "mal ejemplo" sacas unas generalizaciones que hay que agarrarse a la butaca :).
el hilo es deprimente compadezco al autor de ItsNat, no se lo merece.
Afortunadamente algunos sabemos/podemos mantener una discusión con distintos puntos de vista sin "deprimirnos" y como jmarranz y yo nos conocemos personalmente, pues me da en la nariz que es el caso. Si no es el tuyo, pues entonces lo siento por tí, siempre puedes no leerla.
Para un hilo que no es "Java ha muerto, viva X!"...
greeneyed: ya se nota que le tienes tirria a JSF
No es tirria, es la constatación de los innumerables *bandazos* (JSF y EJB) que ha dado la tecnología en teoría más estándar, estable y madura. Si te fijas has tenido que recurrir a ejemplos de "compatibilidad asegurada" con el tercer decimal, 5.2.0 => 5.2.1, 1.4.1 => 1.4.2, obviamente para no pillarte los dedos.
Si te fijas, ahora el tercer decimal en Java es el segundo, y en cambio los parches son ya más del tercero ;).
En cuanto a los bandazos... es lo que pasa en las "especificaciones diseñadas por comité". Si juntas miembros que sólo quieren competir entre ellos y robarse clientes, disimulando un poco concediendo algo de compatibilidad, con algunos que quizá no tengan tan mala baba pero sólo piensan en aplicaciones mega-trifásicas empresariales de trillones de lineas de código olvidándose del 90% del mercado... lo juntas con "cuestiones políticas" y el "no pillarse los dedos" y el "crear una especificación antes de que las buenas prácticas hayan surgido de la experiencia" y te salen engendros como EJB 1.1, por ejemplo, y a partir de ahí todo es cuesta abajo para intentar volver al camino... cosa que no ocurre hasta que alguien da un golpe de timón, en este caso JPA y aun le queda.
Pero ojo que lo opuesto de "esto me sirve a mi y por tanto es lo mejor del mundo mundial y todo el mundo debería usarlo" es igual de malo y pensar que productos y especificaciones son comparables es un craso error.
En todo simplemente lo que queríamos decir es que los números de versión son una forma de enviar un "mensaje" a tu comunidad y es una herramienta útil para dar algo de seguridad y confianza. No todo el mundo empieza leyendose todas las release notes para averiguar las cuestiones de compatibilidad entre versiones y si ves un ejemplo para una tecnología 1.1, si lo pruebas en la 1.4 esperas que funcione más o menos igual, en una 2 quizá pero no es una sorpresa si algo ha cambiado. En cambio si ves un ejemplo de una 1.1, lo pruebas en la 1.4 y resulta que tienes que ir mirando los cambios incompatibles entre la 1.4, 1.3, 1.2 y 1.1... yo por mi parte lo mando al carajo. Quizá haya otros que lo hagan, pero es que yo "no tengo criterio".
Saludos,
primeramente dar las gracias a jmarranz por haber tenido la paciencia en contestarme tan generosamente a la ráfaga de preguntas que le he hecho.
Con respecto al JavaScript, como siempre, llevas toda la razón. Tuve un lapsus ya que intentaba referirme al AJAX (no al JavaScript)en su aspeto asíncrono de comunicación con el servidor, en el cual se pueden realizar peticiones y la ejecución continua sin esperar a que se procesen dichas peticiones.
Muchas gracias.
Eduard
Ah vale.
Echa un vistazo a este ejemplo, especialmente leete el "Explanation". Verás los tres modos de sincronismo AJAX posibles en ItsNat.
Escribe tu comentario