Pregunta

Me gustaría crear una aplicación web AJAX interactiva respaldada por una base de datos que tenga un sistema de calendario personalizado (tipo específico de eventos, edición).Esto implicaría bastante JavaScript y AJAX, y pensé en Google Web Toolkit para la interfaz y Ruby on Rails para el lado del servidor.

¿Es Google Web Toolkit confiable y bueno?¿Qué riesgos ocultos podrían existir si elijo Google Web Toolkit?¿Se puede combinarlo fácilmente con Ruby on Rails en el lado del servidor?¿O debería intentar utilizar directamente una biblioteca de JavaScript como jQuery?

No tengo experiencia en desarrollo web, excepto algo de HTML, pero soy un programador experimentado (c++, java, c#) y me gustaría utilizar sólo herramientas gratuitas para este proyecto.

¿Fue útil?

Solución

RoR es en realidad una de las cosas con las que GWT está diseñado para funcionar bien, siempre y cuando uses REST correctamente.Está en el libro Aplicaciones de Google Web Toolkit y puede ver una demostración del libro que utiliza este tipo de idea. aquí.Eso no quiere decir que no tendrás ningún problema, pero creo que definitivamente hay soporte disponible para ello.

Hay un interesante proyecto para facilitar RoR/GWT que puedes encontrar aquí (Licencia MIT).No he tenido la oportunidad de probarlo todavía, pero parece que se ha pensado mucho en ello.Un inconveniente es que parece que aún no se ha probado completamente con 2.1 Rails, solo 2.0, por lo que puede encontrarse con algunos errores (probablemente menores y reparables).

Otros consejos

Si busca integrar GWT con backends que no sean Java, como ROR, PHP, etc., debe tener en cuenta que GWT 1.5 ahora admite tipos de superposición de JavaScript.Esta característica le permite escribir clases que se pueden asignar sobre objetos JavaScript nativos para proporcionar fácilmente métodos de acceso para las propiedades de esos objetos y otras funciones extendidas.

Vea este enlace para más detalles:Tipos de superposición de JavaScript

Por lo tanto, podría devolver datos codificados en JSON desde su backend a través de llamadas AJAX, analizarlos en un objeto JavaScript y luego acceder a los datos a través de su código GWT Java utilizando las clases superpuestas que ha creado.O cuando renderiza su página, puede renderizar datos de configuración estáticos como objetos JavaScript y leerlos a través de este mecanismo, en lugar de tener que hacer una llamada AJAX para capturar los datos.

Si conoce JAVA y tiene algún lugar donde pueda alojarlo (como un contenedor Tomcat o Glassfish), lo recomendaría mucho más que usar Ruby para el back-end.La razón principal es que luego puede compartir todos sus objetos y utilizar el mecanismo RPC integrado.He hecho esto para muchos de nuestros proyectos y es un gran ahorro de tiempo, sin mencionar que el código es menos propenso a errores, porque no conviertes tus objetos Java en nada y luego vuelves a hacerlo.

He vinculado mi GWT con Rails antes, usando la función to_json en Rails y luego leyendo el JSON en GWT.Todo es compatible, pero es mucho más molesto que simplemente hacer el backend en JAVA.

Por supuesto, si tiene alojamiento barato, entonces los contenedores de Java están prácticamente fuera de discusión, en cuyo caso creo que Rails sería la mejor opción.

GWT es de muy alta calidad con una gran comunidad.Sin embargo, necesita conocer CSS si desea ajustar el aspecto de las cosas (lo hará): CSS puede hacer gran parte del diseño, al igual que la web normal, si así lo desea.Bibliotecas como GWT-ext o ExtGWT pueden ayudar un poco, ya que tienen un aspecto impresionante "listo para usar", pero por un precio (tamaño adicional para su aplicación).

Puede codificar todo en Java usando GWT y puede integrar bibliotecas de JavaScript de terceros existentes con él.Es muy bueno.Nunca he usado mucho RoR, así que no puedo decir nada al respecto.

Si tienes experiencia en Java pero no en Javascript/CSS, entonces GWT te salvará la vida (a menos que quieras aprenderlos, por supuesto).CSS tiene tantos pequeños detalles complicados.No es raro pasar medio día arreglando una desalineación de 2 píxeles que sólo ocurre en IE6.

No estoy seguro de qué tan fácil sería usar ROR para el back-end...Estoy seguro de que es posible, ya que la comunicación GWT ajax son solo servlets.Pero proporcionan una funcionalidad realmente interesante para pasar objetos Java de un lado a otro que no podrá utilizar si su servidor no utiliza también Java.

Escribí sobre algunos de las desventajas de GWT recientemente.Principalmente las desventajas son:Ciclo de implementación largo para cambios en algunas partes de la aplicación y una curva de aprendizaje bastante pronunciada.Como programador Java experimentado, el segundo debería ser un problema menor y si usa un backend separado, el primero también se mitiga (ya que se requiere principalmente una reimplementación completa cuando cambia la parte del 'servidor' de la aplicación).

GWT es un marco maravilloso con mucho potencial.Sin embargo, tenga en cuenta que todavía es bastante nuevo.Hay algunos errores sin resolver que realmente pueden molestarle y, por lo general, requieren soluciones feas para solucionarlos.La comunidad es excelente, pero probablemente tarde o temprano terminarás con algunos problemas que Google no puede resolver todavía.

Pero bueno, yo digo que lo hagas.El potencial de GWT es asombroso y apuesto a que su futuro será brillante.

Definitivamente deberías usar GWT para un proyecto nuevo (también es bastante fácil de usar en un proyecto antiguo).

Según mi experiencia, es muy rápido de aprender y utilizar.El código javascript compilado es mucho mejor que cualquier cosa que puedas escribir a mano y también funciona rápido.

Otro beneficio es la capacidad de depurar su código (lo cual es un infierno solo con JavaScript)

Este blog tiene aportes de muchos usuarios experimentados de GWT y tiene excelentes puntos de discusión.Personalmente tengo una gran experiencia con diversos marcos de interfaz de usuario.Agregaré mis dos centavos.Miremos a fundamental ventajas y desventajas de GWT

Ventaja fundamental

GWT lleva la programación de la capa web a JAVA.Entonces, las ventajas obvias de Java comienzan a entrar en juego.Proporcionará programación orientada a objetos.También proporcionará excelentes comprobaciones de depuración y tiempo de compilación.Dado que genera HTML y Javascript, también tendrá la capacidad de ocultar cierta complejidad dentro de su generador.

Desventaja fundamental

La desventaja parte de la misma afirmación.GWT lleva la programación de la capa web a JAVA.Si conoce JAVA, probablemente nunca buscará un lenguaje alternativo para escribir su lógica empresarial.Es autosuficiente y genial.Pero cuando se trata de escribir configuraciones para una aplicación JAVA.Usamos archivos de propiedades, base de datos, XML, etc.Nunca almacenamos configuraciones en un archivo de clase JAVA.Piensa bien, ¿por qué es eso?

Esto se debe a que la configuración es un dato estático.A menudo requiere jerarquía.Se supone que es legible.Nunca requiere compilación.No requiere conocimientos del lenguaje de programación JAVA.En definitiva, es un juego de pelota diferente.Ahora la pregunta es, ¿cómo se relaciona esto con nuestra discusión?

Ahora, pensemos en una página web.¿Crees que cuando escribimos una página web escribimos una lógica de negocio?Absolutamente no.La página web es solo una configuración.Es una configuración de contenedores y campos jerárquicos.Necesitamos escribir una lógica de negocios para los datos que se capturarán y mostrarán en la página web y no para crear la página web en sí.

El párrafo anterior hace una declaración muy, muy fuerte.Esto explicará por qué las páginas web basadas en HTML y XML siguen siendo las más populares.XML es lo mejor en los negocios para escribir configuraciones.Un marco debe permitir una separación clara entre la página web y la lógica empresarial (el objetivo del marco MVC).Al hacer esto, un diseñador web podrá aplicar sus habilidades de visualización y arte para crear páginas web de aspecto brillante simplemente configurando XML y sin preocuparse por las complejidades de un lenguaje de programación.Los desarrolladores podrán utilizar lo mejor de JAVA empresarial para escribir lógica empresarial.

Finalmente, hablemos de las repercusiones en términos directos.GWT infringe este principio, por lo que está destinado a fallar.El costo de desarrollar una aplicación GWT será muy alto porque necesitará programadores con múltiples habilidades para escribir páginas web.La apariencia requerida será muy difícil de lograr.El tiempo de respuesta para modificar la página web será muy alto debido a una compilación innecesaria.Y, por último, dado que estás escribiendo páginas web en JAVA, es muy fácil corromperlas con lógica empresarial.Sin saberlo, introducirás complejidades que debes evitar.

También podrías considerar Griales ("Groovy on Rails") que le brinda los beneficios de un marco Rails y el uso de Java VM.

Nuestro equipo hizo recientemente la misma pregunta y decidimos optar por GWT, especialmente porque el complemento de diseñador hizo que trabajar con GWT fuera más accesible para los expertos del equipo que no son expertos en Java.¡Quien haga esta elección, tenga cuidado de NO utilizar el complemento GWT Designer!No se ha actualizado (al menos en un año, aparentemente) para crear una aplicación GWT que sea compatible con IE8.

Nuestro equipo casi había completado los diseños de nuestras aplicaciones, que funcionaban perfectamente en Chrome, FF y Safari.Luego explotaron en IE.IE 7 cargaba páginas parciales (pero no incluye páginas compuestas), e IE8 ni siquiera podía cargar la aplicación.Simplemente colgó.

El complemento del diseñador tiene botones que permiten al usuario agregar widgets de CellTable que no son compatibles con IE (CellTable, DeckPanel, Panel horizontal, Panel vertical, entre otros).Esto causará un dolor intenso cuando los diseños tengan que rehacerse en Java sin la ayuda del diseñador.

A los usuarios experimentados de GWT les encanta, pero el complemento de diseño te matará.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top