¿Los peligros de usar ExtJS en un gran proyecto con RoR?

Question

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

¿Alguien tiene alguna experiencia y consejos 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í?

EDIT:

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.

Answer 1

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 que se establece su configuración registro activo para que no incluya el nombre de la raíz del modelo en el JSON, por lo que JsonStore de Ext tiene ningún problema de lectura de los registros. Hay una opción en ActiveRecord BASE llamada include_root_in_json que debe establecer en falso.

• Asegúrese de definir correctamente 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.

• Probablemente querrá 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.

• Sin duda hacer uso de objetos WindowManager y StoreManager de Ext, o hágalo usted mismo de Ext.util.MixedCollection

• Desarrollar el código en archivos separados, manejables, y luego tener un proceso de construcción, que las combina en una sola archivo, y luego ejecute el compresor de YUI o Dean Edwards Packer en él para comprimir/ofuscar el archivo. Sirva todos los JS y CSS en sus propios archivos individuales, incluidos los provistos por Ext.

Answer 2

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. Empecé con esto y pirateé sus extensiones ActiveRecord/ActionView hasta que hiciera lo que necesitaba.

Answer 3

Tengo cierta experiencia en el uso de ExtJS con Rails también. 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.

Éstos son mis quejas con el uso del marco

1. Realmente no se puede hacer uso del flash [: aviso] desde una sola aplicación recargando la página es tonta. 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 mucha de la lógica en las devoluciones de llamada json.

Answer 4

[actualización 2012] ExtJS fue adquirida por Sencha, who offer a GPLv3 license, y dos licencias comerciales.

[comentario 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.

Estoy en contra de usar ExtJS por razones morales.

Answer 5

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. 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.

que adoptó el convergente en las personas de mediana estrategia, que incluye:

• Extender Ext.data.Store y Ext.data.Record estar al tanto de los carriles convenciones de enrutamiento
• Hack Ext.grid.EditorPanel y Ext.form.BasicForm jugar bien con las asociaciones de ActiveRecord
• Escriba algunos módulos para ampliar ActiveRecord::Base y ApplicationController para confirmar simplemente desde Ext.grid.EditorPanel y Ext.form.BasicForm

Eso es más o menos la misma.

Una vez dicho esto, hay algunas desventajas 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.
• que viene del mundo RoR centrado en el Faro de Github /, utilizando VBulletin es como despertarse en 1998. Es decir, no hay bugtracker pública sólo un mensaje del foro que se actualiza (WTF?).
• El código está un poco sobrediseñado.
• El equipo ha perdido la credibilidad de código abierto por lo que han perdido el oxígeno de código abierto.
• El equipo parece estar enfocado en la integración con GWT (¿alguien puede decir "enterpri $ ey"?).

Answer 6

Si bien no tengo experiencia de ExtJS (además de leer en el libro "Practical Rails Projects") que se utiliza un jQuery Flexigrid con jrails para obtener más de un ambiente de escritorio.

Eso funcionó bastante bien.

Answer 7

He desplegado ExtJS y rieles para una serie de aplicaciones y que sin duda se puede hacer para hablar unos con otros. Hemos creado una demostración rápida de una aplicación que estamos desarrollando actualmente en Rails + Ext al http://demo.domine.co.uk/admin. No haga caso de la parte delantera por el momento ya que no es completa - la sección de administración está esencialmente terminada y que puede conectarse a ella con:

nombre de usuario: Edward contraseña: rarrar

Como la demo no ha terminado por completo todavía Gané No garantizo 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 servidor a través de los carriles 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 ...

Answer 8

Esto pertenece en respuesta al comentario de Milán en mi respuesta anterior, sino como un recién llegado aquí no tengo suficientes puntos de reputación de descontar por ahí:

Hubo un problema con el "SP es indefinido", que fue el resultado del almacenamiento en 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 haya encontrado las cosas de Ext MVC anteriormente. 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 refacturación de 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 intentar 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.

Answer 9

Ok. 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. link text

Answer 10

Es posible que desee echar un vistazo al marco Netzke que se piensa para hacer precisamente eso: facilitar la creación de una página compleja aplicación web con énfasis en el enfoque modular.

Las ventajas de Netzke son:

• reutilización 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 prediseñados que puede utilizar de inmediato sin siquiera tocar Ext JS (justo configurarlos en Rails)

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

desventajas de Netzke son:

• El código es aún joven, y la comunidad pequeña.

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

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