2009-04-13 18 views

Respuesta

7

Trabajé con GWT hace aproximadamente un año. En el momento que parecía una gran idea, con una serie de salvedades:

  • que había "pifias" problemas con algunas partes de la API, que probablemente estaban relacionados con el hecho de que usted es la codificación como si Está en Java cuando en realidad está escribiendo para un entorno compilado por separado que actúa como java, por lo que hace algunas suposiciones incorrectas (en este caso, pasar valores anidados a la interfaz). Creo que había otro que estaba reescribiendo mis scripts de hormiga para usar un jvm de 32 bits para la compilación de gwt.
  • Pasé un tiempo tratando de modificar el aspecto: nunca desplegamos un proyecto terminado, así que no estoy seguro de cuánto trabajo habría llevado esto para llegar a un nivel profesional, pero parecía (lógicamente) igual Sería comparable a ajustar una interfaz de swing. tal vez un poco más difícil de manejar, visualmente, que html.
  • Debido a que el ajax está tan oculto para ti en el producto final, tuve algunas preocupaciones sobre lo que podría hacer si el rendimiento fuera pobre.

Habiendo dicho eso, definitivamente parece que vale la pena jugar, y mis experiencias fueron hace mucho, mucho tiempo en Internet, especialmente teniendo en cuenta que ahora es probablemente mucho más maduro. También vale la pena señalar que es una forma muy diferente (y refrescante) de desarrollar código GUI desde la mayoría de los frameworks MVC, y vale la pena echarle un vistazo si no es por otra razón que eso.

Mi sensación es que si está construyendo un sitio profesional de alta carga con requisitos gráficos muy exigentes, GWT probablemente no sea una buena opción; de lo contrario, está bien.

+0

Mi preocupación es que no es tan intuitivo escribir código Java para generar una interfaz visual. No parece que realmente tuvieras ese problema. No pensé en ajustar el ajax, podría ser demasiado complicado molestarlo, diría yo. Me pregunto qué tan diferente es GWT de cuando lo usaste. – karl

+0

No estoy seguro de por qué dice esto: "Mi sensación es que si está construyendo un sitio profesional de alta carga con requisitos gráficos muy exigentes, GWT probablemente no sea una buena opción; de lo contrario, está bien", ¿es porque GWT es "pesado" en el navegador - en cuanto al rendimiento? – karl

+0

Dada la seriedad de sus advertencias, me sorprende que no me esté hablando de ello. Pero parece que piensas que estas preocupaciones son superadas por. . . ¿Qué? No veo muchos aspectos positivos aquí :) – karl

1

GWT es relativamente nuevo. El proceso de compilación tiende a ser un poco lento a medida que crece su base de código. Cuando trabajamos con él encontramos muchos problemas con el diseño y la representación de widgets más sofisticados, y el emulador actuó de forma totalmente diferente a los servidores reales. Además, tuvimos problemas con i18n para idiomas de derecha a izquierda ...

En general, GWT tiene (¿los problemas habituales?) Problemas de las tecnologías jóvenes. Sin embargo, hace que ciertas cosas sean realmente fáciles, como Ajaxifying como lo llamaste.

+0

¿Te refieres a Java en general? Todo el equipo tiene años de experiencia ... – abyx

+0

Me sorprende escuchar esto. ¿Cuán experimentado eres con las tecnologías Java? – karl

+0

Sí, me refería a Java en general. No estaba seguro de si sus problemas fueron el resultado de la falta de familiaridad con la forma de hacer las cosas en Java. – karl

1

Hemos hecho esto para un proyecto muy grande, y siempre que sepa sus limitaciones, fortalezas y debilidades, funciona de maravilla. Curiosamente, la presentación fue la menor de nuestras molestias, ya que simplemente lo despellejamos como lo haría con cualquier otra página HTML, utilizando CSS. El proyecto se puso en marcha y funcionó impecablemente, así que no tengo quejas.

Las trampas he encontrado con ella se puede encontrar aqui:

Biggest GWT Pitfalls?

2

Se mencionaron que GWT se ocuparía de la capa de presentación. ¿También estarías haciendo la capa de negocios en Java? Si ese es el caso, me gustaría señalarle hacia IT Mill Toolkit, que hace exactamente esto: es un conjunto de herramientas que utiliza GWT para representar sus componentes de GUI, lo que le permite realizar sus aplicaciones completamente en Java. Creo que el término que trata de acuñar es "RIA controlado por el servidor".

Vengo de un fondo PHP, pero al instante me gustó el kit de herramientas.Pero es probable que sea mejor no decir nada más y dejarte tomar tus propias decisiones.

Descargo de responsabilidad: Trabajo en IT Mill, aunque eso es irrelevante para mis opiniones.

+0

Supongo que no está permitido que le guste el producto con el que trabaja a diario ... –

+0

Probablemente no, si le cuesta dinero ... aunque la publicación es CW, no importa lo que piense la gente :) –

+0

Bill: el kit de herramientas es gratuito como en cerveza y código abierto. Ah, y no estoy preocupado por la reputación, CW o no. Simplemente me desconcertaban las reacciones. Quiero decir, si hubiera guardado un "secreto" de que, efectivamente, mi empresa me paga, ¿hubiera sido mejor? Probablemente se hubiera frito más duro, si alguien hubiera notado lo que omití, supongo. –

1

Hemos desarrollado una aplicación a gran HR Portal con toda la capa de presentación realizado en GWT. El backend es Spring. Todo funciona muy bien y la interfaz de usuario ha sido muy bien recibida por los usuarios. Es muy importante para nosotros agregar nuevas funcionalidades y mantener la aplicación. Creo que sería mucho más difícil hacer algo comparable y fácil de mantener utilizando las bibliotecas de Javascript.

Necesitas algún tipo de marco de trabajo del lado del cliente o terminarás escribiendo uno (como lo hicimos nosotros!): Nuestra aplicación está construida en GWT Portlets (fuente gratuita y de código abierto).

Utilizamos fragmentos de HTML para aplicar diferentes aplicaciones a la aplicación y el diseño de cada "página" se almacena en un archivo XML.

-1

GWT en sí mismo es una biblioteca de mejora de interfaz de usuario, no un marco. Si lo usa con Google App Engine, entonces tiene un marco básico. (Esa es una historia diferente, y aunque la miré, decidí no incluir eso en nuestra arquitectura).

Es una gran biblioteca, hemos hecho algunas cosas espectaculares con ella. Sin embargo, como es una biblioteca, solo es tan buena como lo permite su arquitectura.

En lo que respecta a ANT, no hay problemas con un compilador de 64 bits.

< java FailOnError = "true" tenedor = "true" nombre de clase = dir "com.google.gwt.dev.Compiler" = "$ {} dir.GWTCompile" > < - dir.GWTCompile es el directorio que contiene GWT - > < ruta de clase > ruta de clase </ruta de clase > < valor jvmarg = "- $ {} gwt.maxMem" valor arg/> < = "@ {} gwt.baseModule"/> < valor arg = "DEBUG"/> < arg value = "- estricta"/> </java >

Por lo que el código generado, es todo lo que hay en su guerra si usted quiere mirar a través de él. (También es de código abierto, por lo que puede verlo allí.)

Lo que hace GWT durante el proceso de compilación: Crea varias copias de bibliotecas JS para diferentes conjuntos de exploradores (Una razón por la que puede tardar minutos en compilarse) , puede agregar/eliminar estos según sea necesario. Esto reduce el paquete JS que debe descargarse y aumenta la velocidad, ya que no tiene que ser tan desagradable si (EI) este otro si (FF) eso. Sin embargo, cuando realiza la depuración local (al menos en eclipse) no tiene que esperar, lo que le permite dejar eso para el servidor de compilación (o cuando necesita compilar e implementar manualmente (neandertales)).

La desventaja de GWT. Como es un lado del cliente de JavaScript (casi puramente), no puede utilizarlo para las cosas que no lo admiten, o admite una de las versiones. Por lo tanto, para cosas como iPads y iPhones puede tener algunos problemas si no usa bibliotecas adicionales diseñadas para cerrar esas brechas (como mgwt).

Cuestiones relacionadas