tutorial showcase google examples ejemplos java javascript ajax gwt

showcase - gwt java tutorial



Por qué GWT? Ventajas y ventajas del uso de este marco de RIA (3)

Compensaciones

Comencemos con todas las ventajas y desventajas que se me ocurren:

  • estás usando Java , significa que el dominio de tus webdevs en javascript no será tan útil (será útil si te dedicas a JSNI)
  • problemas con la indexación por los motores de búsqueda - en mi humilde opinión, esta debería ser la mayor desventaja de usar GWT, o aplicaciones web JS puras en general. Dado que el contenido, el diseño y todo se crea "sobre la marcha" con JS, el motor de búsqueda solo verá una página HTML muy corta y eso es todo: usted tiene que encargarse de esto de alguna manera (por ejemplo, usando el cloaking ). . Google finalmente ha comenzado a trabajar en una solución para esto , sin embargo, no parece atractivo para mí.
    Actualización: Google finalmente ha resuelto este problema. Sin embargo, dejaré esto como una compensación porque hacer que la aplicación sea rastreable aún requiere más esfuerzo que en otros marcos. Al menos ahora tenemos un "estándar" a seguir y no tenemos que usar algunas técnicas dudosas (como el cloaking ).
  • es fácil (especialmente para un principiante en GWT, especialmente cuando esa persona proviene de un fondo HTML / JS - sin demasiada experiencia orientada a objetos) para ir todo "wow, estas cosas de ''objetos'' son tan geniales, déjame hacer todo mi <div> s en objetos separados, que harán que el código sea agradable y ordenado ". Por supuesto, lo exagero exageradamente, pero entiendes el punto: es fácil imaginar que un programador inexperto podría poner un Widget completo con muchos Handlers en cada celda de una FlexTable ... Y luego (s) perderá mucho tiempo preguntándose por qué la aplicación se siente lenta;) tl; dr: es fácil para los principiantes en GWT hacer que sus aplicaciones sean "infladas" al escribir código que parece estar en línea con lo que la documentación / muestras / sentido común; ) sugerir

Eso es todo por las concesiones que puedo pensar: si alguien quiere agregar algo, por favor agregue comentarios.

Ventajas

Ahora por las ventajas. Voy a omitir algo como la internationalization , la compatibilidad entre navegadores de forma gratuita, la integración fácil con otras bibliotecas de Google, etc., porque son un tanto obvias y fáciles de entender. Trataré de enfocarme en las características menos destacadas pero aún muy importantes:

  • el compilador , ahora, la mayoría de las personas con las que he hablado sobre GWT no se da cuenta de lo increíble que es esta parte de GWT, para empezar, pruebe esta presentación del Google IO del año pasado . El compilador tiene la vista de toda la aplicación.

Entonces puede optimizar algo como esto:

public class ShapeExample implements EntryPoint { private static final double SIDE_LEN_SMALL = 2; private final Shape shape = new SmallSquare(); public static abstract class Shape { public abstract double getArea(); } public static abstract class Square extends Shape { public double getArea() { return getSideLength() * getSideLength(); } public abstract double getSideLength(); } public static class SmallSquare extends Square { public double getSideLength() { return SIDE_LEN_SMALL; } } public void onModuleLoad() { Shape shape = getShape(); Window.alert("Area is " + shape.getArea()); } private Shape getShape() { return shape; } }

..a esto:

public class ShapeExample implements EntryPoint { public void onModuleLoad() { Window.alert("Area is 4.0"); } }

Y luego ofuscar esto y minimizar. Además, esto se hace de tal manera, que hace que los archivos resultantes sean más compresibles a través de gzip.

  • está usando Java , le guste o no Java, no se puede negar que es un lenguaje orientado a objetos muy bueno, que permite escribir código fácil de mantener y comprobable (algo que no creo que sea posible con JavaScript). ) Si sigues algunas buenas pautas , llegarás a un código que es comprensible no solo para ti, sino también para otros desarrolladores. Otra cosa que vale la pena mencionar es que todos esos patrones de diseño agradables, etc., que funcionan en Java "puro", también funcionan aquí.
  • Una cosa ingeniosa acerca de GWT es que obtiene mejoras de rendimiento y nuevas características de forma gratuita con casi todas las versiones nuevas del marco. Dado que se compila en JavaScript con JavaScript, solo se necesita una recompilación para beneficiarse de las optimizaciones realizadas en el nuevo compilador u obtener nuevas características (como el soporte de accesibilidad introducido en GWT 1.5).
  • depuración : vale la pena mencionar que puede (y debe :)) depurar sus aplicaciones GWT al igual que cualquier otra aplicación Java, utilizando el depurador IDE. Y, en general, los depuradores de Java que he visto son más avanzados que sus homólogos de JavaScript.
  • UiBinder : si bien aún no es "perfecto", UiBinder permite diseñar tus widgets de una manera fácil e intuitiva usando XML (a diferencia de la forma anterior a 2.0 que te obligó a hacer esto en Java). Mezclar HTML y Widgets de GWT nunca ha sido tan fácil y divertido;)
  • Trabajando con CSS : GWT siempre, por supuesto, adoptó CSS, pero con la introducción de GWT 2.0 (y UiBinder) lo llevaron a otro nivel. Miremos un archivo CSS desde una aplicación web "normal": cientos, si no miles de líneas, difíciles de navegar, algunos estilos son redundantes pero es difícil darse cuenta de que, algunos no se usan para nada, agregue a esta mezcla necesito complacer IE6 / 7 y te haces una pesadilla. Con GWT, puede indicarle que realice las tareas similares que hizo para el código JS para CSS, de modo que poderá todos los estilos CSS no utilizados, se fusionará cuando sea apropiado, minimizará y ofuscará los nombres de las clases, y muchos más (incluidos los condicionales, las constantes) , etc. en tus archivos CSS). Le recomendamos que mantenga sus estilos en sus respectivos archivos XML de UiBinder, lo que hace que organizarlos y encontrarlos sea mucho más fácil. Por último, pero no por ello menos importante, se produce un error al escribir mal el nombre de un estilo de CSS, sin problemas y luego intentar hacer lo mismo a través de Firebug o una herramienta similar.
  • OOPHM - Modo alojado fuera de proceso, con esto, arreglaron una de las mayores desventajas de GWT: ahora, puedes usar el modo alojado en el navegador de tu elección (si esa opción es Firefox, Safari, IE o Chrome, pero en al menos puedes usar cualquier versión que desees). El diseño de OOPHM también te permite hacer cosas geniales como ejecutar Windows en una VM, y conectarte desde el IE allí al modo alojado que se ejecuta en el sistema operativo host (Linux / MacOS): no necesitas hackear, copiar archivos después de cada compilación, etc
  • puedes decir / ɡwɪt / mucho;) (esta es una cita de una de las presentaciones en Google IO 2009 , IIRC)
  • muchos más. Echa un vistazo a los videos de Google IO 2009 y navega por la wiki de GWT para ver más cosas que hacen que la creación de RIA sea más fácil y menos propensa a errores con GWT :)

Entre

Dependiendo de su experiencia y / o preferencias, lo siguiente puede ser una ventaja (es para mí, pero a veces es un PITA;)) o no:

  • la colección de widgets listos para usar se mantiene pequeña y simple . Ahora, si proviene de un marco de GUI completo (ya sea en la Web o en el escritorio), se sorprenderá de lo relativamente pequeño que es el número de Widgets GWT. Pero de acuerdo con los desarrolladores de GWT, se mantiene así a propósito: los widgets básicos son todas las herramientas / "bloques" que necesita para crear sus propios widgets, personalizados según sus necesidades. La alternativa es proporcionar una variedad de widgets de uso múltiple que tengan que admitir muchos casos de uso ... El resultado es una IU un poco lenta (al menos en mi humilde opinión: compruebe usted mismo proyectos como SmartGWT o Ext GWT ). Es decir, los Widgets de GWT están muy bien escritos, por ejemplo, el SuggestBox tiene muchos lugares donde puedes anular el comportamiento predeterminado con el tuyo, puedes especificar una manera diferente de mostrar las sugerencias ( SuggestBox.SuggestionDisplay ), disparar un acción personalizada cuando el usuario selecciona una sugerencia ( SuggestBox.SuggestionCallback ) o simplemente proporciona un SuggestOracle personalizado para alimentar el SuggestBox con Suggestion s ...

La conclusión es - prueba GWT, es probable que te encante y nunca más quieras escribir en JavaScript puro;)

He estado leyendo un montón de las "preguntas más votadas" para GWT. Varias de estas preguntas hablan sobre las trampas o problemas con GWT.

En los artículos: ¿Qué marco de Javascript (jQuery vs Dojo vs ...)? y las mayores trampas de GWT? , algunos carteles parecen sugerir que GWT no es lo suficientemente liviano o que hay mejores alternativas que pueden usarse.

¿La mayoría de ustedes siente que hay problemas con GWT que no se han resuelto con GWT 2.0, lo que lo inclinaría a sugerir utilizar un marco más simple para un nuevo proyecto?

Hasta cierto punto, ¿no debería GWT ser un tanto a prueba de futuro (ya que no tienes que preocuparte porque cambie drásticamente de un lanzamiento a otro y porque está respaldado por Google)?

Me doy cuenta de que la respuesta a esta pregunta depende en gran medida de lo que quiere hacer o lo que desea hacer. Estoy mirando esto desde la perspectiva de comenzar una nueva aplicación web que eventualmente será utilizada por millones de usuarios.

Estamos construyendo sistemas empresariales pequeños (~ 2K clases Java) a medios (~ 6K) de forma regular utilizando GWT desde que salió la versión 1.3. Entiendo que hay un conjunto diferente de problemas para resolver en un sitio público con miles de clics por segundo, pero trataré de hablar sobre nuestros mayores problemas en GWT 1.xy cómo se acerca GWT 2.0.

Fugas de memoria del navegador Las fugas de IE6 con GWT son tremendas, las fugas de IE7 se pueden compensar con actualizaciones de página periódicas, IE8 promete algo de estabilidad en esta área, pero aún no es ampliamente aceptado en la empresa. Y sí, incluso el código GWT válido sin llamadas JS nativas pierde memoria en ciertos casos. Especialmente cuando la IU es compleja y usted está haciendo un montón de llamadas Panel.clear (). No hay herramientas útiles para identificar la causa real de la fuga en este momento. A menos que sepa cómo piratear el navegador.

Rendering Performance tiene que escribir su código de UI con mucho cuidado, especialmente al crear widgets personalizados de uso común. Aún se requiere conocimiento profundo de JavaScript, CSS y DOM. Hay muchos materiales en internet sobre este tema. Necesita saber cómo y cuándo bajar desde el nivel de widget GWT para dirigir las manipulaciones DOM.

Tamaño del contenido descargable Antes de 2.0 era imposible dividir el módulo en diferentes piezas descargables sin tener una navegación "dura" incorporada en la aplicación. Pero eso borrará el contexto de JavaScript y requerirá la recarga de la ventana.

UI Developers Mind Shift Los desarrolladores de UI experimentados simplemente no conocen Java y OOP. Los desarrolladores experimentados de Java no conocen CSS, JS, HTML y no les gusta construir UI. UI Binder va en la dirección correcta.

Hemos hecho la migración 1.3 -> 1.5 -> 1.7 y siempre fue solo una recompilación y un par de correcciones de CSS. GWT 2.0 elimina una gran cantidad de códigos obsoletos y enfoques iniciales (estructura del proyecto, GWTShell) y puede ser complicado migrar rápidamente. Pero todas las características parecen prometedoras y es bueno que Google haya eliminado el código heredado en algún momento. Sin embargo, no estoy seguro de la estabilidad de 2.0, ya que aún no lo hemos usado en proyectos reales.

Espero que esto ayude.

Tenemos una aplicación GWT con un montón de pruebas de aceptación de Selenium. Pensé (como usted) que seguramente sería seguro actualizar GWT de 1.7 a 2.0. Y fue, en su mayoría. La aplicación todavía funcionaba igual para los usuarios "humanos", pero las pruebas de selenio se rompieron todas. Hay una versión más reciente de Selenium en preparación (en versión alpha, con muchas UnsupportedOperations), pero si queremos quedarnos con GWT 2, parece que tenemos que renunciar a cierta capacidad de prueba. Así que tenga cuidado con las suposiciones "a prueba de futuro".

Nuestra decisión de utilizar GWT se tomó hace meses, después de comparar YUI y ZK. Todavía estoy contento de haber elegido GWT. El nivel de soporte en el sitio web de GWT y la calidad general de la documentación parece muy alto.

GWT divide los módulos y proporciona perfiles de rendimiento que ayudan a contrarrestar los argumentos de que no es lo suficientemente liviano.