ruby-on-rails ruby extjs ria rich-internet-application

ruby on rails - ¿Los peligros de usar ExtJS en un gran proyecto con RoR?



ruby-on-rails ria (10)

Estamos desarrollando una aplicación bastante grande usando Ruby on Rails framework (sistema CRM) y estamos considerando reescribirla para usar ExtJS para que Rails simplemente haga el manejo de datos, mientras que ExtJS haría todo el navegador heaviling de una manera similar a la de un escritorio.

¿Alguien tiene alguna experiencia y pistas sobre cuál sería el mejor enfoque? ¿ExtJS es lo suficientemente maduro como para usarse en aplicaciones relativamente grandes (y complejas)? ¿Y qué pasa con la parte de Rails? ¿Cuál sería el mejor enfoque aquí?

EDITAR:

Sólo para que quede claro. Preferiría hacerlo de tal forma que todo el código de la aplicación del lado del cliente de JavaScript se cargue a la vez (al inicio de la aplicación, de manera óptima como un archivo js comprimido) y luego simplemente use ajax para enviar datos hacia y desde Rails. aplicación Además, sería bueno tener ERB disponible para la generación dinámica de los elementos de apliccación Ext.

Actualmente tengo una aplicación de escritorio extremadamente grande escrita en ExtJS. Solía ​​ejecutarse sobre el marco de Catalyst MVC de Perl, pero una vez que toda la capa de Vista se convirtió en un escritorio basado en ExtJS comencé a migrar a los modelos y controladores de Ruby on Rails. Es igual de rápido, si no más rápido, más fácil de mantener y tiene una base de código mucho más pequeña.

  • Asegúrese de configurar su configuración de registro activa para que no incluya el nombre de raíz del modelo en json, para que JsonStore de Ext no tenga problemas para leer los registros. Hay una opción en ActiveRecord BASE llamada include_root_in_json que tiene que establecer en falso.

  • Asegúrese de definir adecuadamente sus clases de Aplicación en Ext y maximizar la reutilización de código y va a querer algún tipo de método para limpiar los nodos no utilizados en el DOM. El rendimiento de Javascript puede ser un verdadero problema a menos que esté utilizando las últimas versiones de Safari o Firefox 3.1.

  • Es probable que desee algún tipo de método de almacenamiento en caché para los datos en el servidor que se servirán a su aplicación en formato JSON en el momento en que se carga la página. Esto reducirá el número de viajes de ida y vuelta por Ajax.

  • Definitivamente haga uso de los objetos WindowManager y StoreManager de Ext, o distribuya los suyos desde Ext.util.MixedCollection

  • Desarrolle su código en archivos independientes y manejables, luego tenga un proceso de compilación que los combine en un solo archivo y luego ejecute el compresor de YUI o Dean Edwards Packer para comprimir / ocultar el archivo. Sirva todos los JS y CSS en sus propios archivos individuales, incluidos los provistos por Ext.

De acuerdo. Utilizo extjs gxt gwt en muchos proyectos, y es muy fácil de desarrollar. Pero quiero decirte que construí mi proyecto con extjs + gwt (gxt), no estoy seguro acerca de Ruby. Texto del enlace

Es posible que desee echarle un vistazo al marco Netzke que se cree que hace precisamente eso: facilitar la creación de aplicaciones web complejas de una página con énfasis en el enfoque modular.

Las ventajas de Netzke son:

  • Reusabilidad y extensibilidad del código. Una vez que haya creado su componente (tanto del lado del cliente como del servidor), puede reutilizarlo en cualquier lugar, combinarlo con otros componentes o extender el evento con herencia.

  • Eficiencia. La clase para cada componente se carga desde el servidor (y se evalúa) solo una vez, lo que ahorra mucho tiempo en la comunicación entre el servidor y el cliente.

  • Es de código abierto, y está en desarrollo activo. Tiene demostraciones en vivo y código de ejemplo.

  • Tiene componentes precompilados que puedes usar de inmediato sin tocar Ext JS (solo configúralos en Rails)

  • Ha sido utilizado (por su autor) para el desarrollo real de una aplicación logística compleja.

Las desventajas de Netzke son:

  • El código todavía es joven y la comunidad pequeña.

Si está interesado, eche un vistazo a la descripción y los detalles de diseño aquí: https://github.com/nomadcoder/netzke-core

Demostración en vivo / tutoriales se pueden encontrar aquí: http://netzke-demo.herokuapp.com y aquí: http://yanit.heroku.com

Esto es en respuesta al comentario de Milan sobre mi respuesta anterior, pero como recién llegado aquí no tengo suficientes puntos de reputación para responder allí:

Hubo un problema con el "sp no está definido", que fue el resultado del almacenamiento en memoria caché de Rails de los archivos JavaScript en un archivo grande (de lo contrario, habría varios cientos de archivos). El almacenamiento en caché introdujo algunos errores extraños con nuevas líneas que arrojaron todo. Esto me hizo sacar el pelo por un tiempo, pero la solución fue actualizar Ruby de 1.8.6 (nivel de parche 72) a la última 1.8.7. Esto solucionó el problema, por lo que debes volver a consultarlo si quieres echarle un vistazo (deberás hacer una actualización completa para superar el almacenamiento en memoria caché de los activos).

Me alegra que hayas encontrado algo de Ext MVC antes. Actualmente, puedo creer que debe ser bastante difícil de entender, principalmente debido a la falta de ejemplos, tutoriales y demostraciones. Sin embargo, el código en sí está razonablemente bien documentado (al menos, el código más nuevo de todos modos, hay mucho que debe eliminarse).

Actualmente estoy en el proceso de refactorizar algunas clases clave antes de que esté listo para una ''versión'' adecuada. Cuando esté listo (estoy pensando en un par de semanas), generaré la documentación y estableceré un sitio rápido con algunas demostraciones y un código de ejemplo. Cuando lo haya hecho, pondré una publicación en mi blog ( http://edspencer.net ).

Mi objetivo con esto es tratar de proporcionar un marco que simplifique la escritura de este tipo de aplicaciones y establecer algunas convenciones. Actualmente no existe un consenso o una forma predeterminada de estructurar las aplicaciones ExtJS, por lo que cualquier cosa que podamos hacer para avanzar será un paso en la dirección correcta. Los comentarios y contribuciones son más que bienvenidos.

Ext es definitivamente lo suficientemente maduro como para manejar esta situación. Actualmente estoy trabajando en un proyecto de Rails con mucho Ext, y la parte más difícil definitivamente ha estado trabajando con to_json de Rails para representar JSON que puede leer Ext (para matrices, hash, modelos, que no han validado, etc.)

Consulte el complemento ext_ scaffold para Rails. Comencé con esto y ActionView extensiones ActiveRecord / ActionView hasta que hizo lo que necesitaba.

Implementé ExtJS y Rails para una serie de aplicaciones y ciertamente se pueden hacer para que hablen entre sí. Hemos creado una demostración rápida de una aplicación que estamos desarrollando actualmente en Rails + Ext en http://demo.domine.co.uk/admin . Ignore el front end por ahora, ya que no está completo: la sección de administración está esencialmente terminada y puede iniciar sesión con:

nombre de usuario: contraseña de edward: rarrar

Como la demo no está completamente terminada, no garantizaré que funcione correctamente en otra cosa que no sea Firefox en esta etapa. No hay ninguna razón para que no funcione en otros navegadores, simplemente no he pasado tiempo probándolos todavía. El punto es más acerca de la integración con los rieles.

Cada aplicación en el menú de inicio está interactuando con el backend de Rails a través de JSON. Escribí un complemento básico de Rails para hacer la mayor parte del trabajo para nosotros allí. Voy a lanzar el código detrás de eso en breve, pero por ahora con suerte eso da una idea de qué tan bien estas dos tecnologías pueden funcionar juntas ...

Implementé con éxito una aplicación RoR / ExtJS grande del tipo que describe (impulsado por AJAX "de una sola página"). Ext_scaffold es una especie de reclamo.

No es demasiado agotador conseguir que RoR y ExtJS funcionen sin problemas juntos. La elección fundamental es si extender ExtJS para "hablar Raíles", parchear RoR para "hablar ExtJS", o reunirse en el medio. Va a depender de las habilidades de su equipo.

Adopté la estrategia de reunirme en el medio, que incluye:

  • Extienda Ext.data.Store y Ext.data.Record para conocer las convenciones de enrutamiento de Rails
  • Hack Ext.grid.EditorPanel y Ext.form.BasicForm para jugar bien con las asociaciones ActiveRecord
  • Escriba algunos módulos para extender ActiveRecord::Base y ApplicationController para simplemente realizar commits desde Ext.grid.EditorPanel y Ext.form.BasicForm

Eso es practicamente todo.

Habiendo dicho eso, existen inconvenientes para ExtJS.

  • Tendrás que ensuciarte las manos en el interior. No se deje engañar por el demos.
  • La documentación de la comunidad es pobre y está centrada en PHP.
  • Viniendo del mundo RoR centrado en Github / Lighthouse, usar VBulletin es como despertar en 1998. Quiero decir, no hay un rastreador de errores público solo una publicación en el foro que esté actualizada (¿WTF?).
  • El código está un poco sobrediseñado.
  • El equipo ha perdido credibilidad Open Source por lo que han perdido oxígeno de código abierto.
  • El equipo parece estar enfocado en la integración con GWT (¿alguien puede decir "enterpri $ ey"?).

Si bien no tengo experiencia en ExtJS (además de leer en el libro " Practical Rails Projects "), utilicé jQuery Flexigrid con jrails para obtener más sensación de escritorio.

Eso funcionó bastante bien.

También tengo experiencia en usar ExtJS con Rails. Usar el marco es una excelente manera de obtener algunos widgets bonitos de forma gratuita. La convención REST también debe estar bien con el marco si la usa para desarrollar aplicaciones de una sola página. Funciona bien con RJS también.

Aquí están mis quejas con el uso del marco

  1. Realmente no se puede usar flash [: notice] ya que volver a cargar una aplicación de una sola página es una tontería. Esto hace que pasar notificaciones y mensajes de validación sea una tarea ardua, ya que tiene que usar los métodos RJS / javascript para mostrarlos.

  2. No puede usar mucho erb, por lo tanto, tiene que encapsular una gran parte de la lógica en las devoluciones de llamada json.

[Actualización de 2012] ExtJS fue adquirido por Sencha, que ofrece una licencia GPLv3 y dos licencias comerciales.

[Comentario de 2008-Oct] ExtJS es excelente en cuanto a los méritos técnicos, pero el fiasco con la licencia hace varios meses me ha llevado a mirar otros marcos: ahora no confío en los creadores de ExtJS. No me gusta cómo redactaron su licencia, y cómo fingieron ser defensores de código abierto, mientras que obviamente intentaban sacar provecho injusto de aquellos que los creían.

Solo estoy en contra de usar ExtJS por razones morales.