We are developing a considerably big application using Ruby on Rails framework (CRM system) and are considering to rewrite it to use ExtJS so that Rails would just do the data handling, while ExtJS would do all the browser heavylifting in a desktop-like manner.
Anyone has some experience and hints about what would be the best approach? Is ExtJS mature enough to be used in relatively big (and complex) applications? And what about the Rails part - what would be the best approach here?
EDIT:
Just to make it clear. I would prefer to do it in such a way that all the javascript client side application code is loaded at once (at the start up of the application, optimally as one compressed js file) and then just use ajax to send data to and from Rails app. Also, it would be nice to have ERB available for dynamic generation of the Ext apliccation elements.
I currently have an extremely large, desktop style app written in ExtJS. It used to run on top of Perl's Catalyst MVC framework, but once the entire View layer was converted to an ExtJS based desktop I started migrating to Ruby on Rails models and controllers. It is equally as fast, if not faster, and easier to maintain and has a much smaller code base.
Make sure that you set your active record config to not include the root name of the model in the json, so that Ext's JsonStore has no problem reading the records. There is an option on ActiveRecord BASE called include_root_in_json you have to set to false.
Make sure that you properly define your Application classes in Ext and maximize code re-use and you are going to want some sort of method to clean up unused nodes in the DOM. Javascript performance can be a real pain unless you are using the latest versions of Safari or Firefox 3.1.
You probably will want some sort of caching method for data on the server to be served to your application in JSON format at the time the page is loaded. This will cut down on the number of round trips via Ajax.
Definitely make use of Ext's WindowManager and StoreManager objects, or roll your own from Ext.util.MixedCollection
Develop your code in separate, managable files, then have a build process which combines them into a single file, and then run YUI's compressor or Dean Edwards Packer on it to compress / obfuscate the file. Serve all JS and CSS in their own single files, including the Ext supplied ones.
[2012 update] ExtJS was acquired by Sencha, who offer a GPLv3 license, and two commercial licenses.
[2008-Oct comment] ExtJS is great on technical merits, but the fiasco with the licensing several months ago have led me to look at other frameworks - I don't trust the creators of ExtJS at all now. I don't like how they worded their license, and how they pretended to be open source advocates whilst obviously attempting to profit unfairly off those who believed them.
I'm only against using ExtJS on moral grounds.
This belongs in answer to Milan's comment on my previous answer, but as a newcomer here I don't have enough reputation points to reply there:
There was a problem with the "sp is undefined", which was a result of Rails' caching of the JavaScript files into one large file (there would be several hundred files otherwise). The caching introduced some weird bugs with newlines which threw the whole thing off. This had me pulling my hair out for a while, but the solution was to update Ruby from 1.8.6 (patch level 72) to the latest 1.8.7. This fixed the problem so please check it again if you want to have a look (you'll need to do a full refresh to beat the asset caching).
I'm glad you've come across the Ext MVC stuff before. At present I can fully believe it must be quite difficult to understand, mainly due to a lack of examples, tutorials and demos. The code itself is reasonably well documented however (at least the newer code anyway, there is a lot which needs clearing out).
I am currently in the process of refactoring a few key classes before it is ready for a proper 'release'. When that's ready (I'm thinking a couple of weeks), I will generate the documentation and set up a quick site with some demos and example code. When I've done so I'll put up a post on my blog (http://edspencer.net).
My aim with this is to try to provide a framework which will make writing this type of application much simpler, and to establish some conventions. Currently there is no consensus or default way of structuring ExtJS applications, so anything we can do to move that along will be a step in the right direction! Comments and contributions are more than welcome.
I've successfully deployed a large RoR/ExtJS app of the kind you describe ("single-page" client-side AJAX driven). Ext_scaffold is pretty much a red-herring.
It's not too taxing to get RoR and ExtJS working smoothly together. The fundamental choice is whether to extend ExtJS to "speak Rails", patch RoR to "speak ExtJS", or meet in the middle. It's going to depend where your team's skills are.
I adopted the meet-in-the-middle strategy, which includes:
Extend Ext.data.Store and Ext.data.Record to be aware of Rails routing conventions
Hack Ext.grid.EditorPanel and Ext.form.BasicForm to play well with ActiveRecord associations
Write some modules to extend ActiveRecord::Base and ApplicationController to simply commits from Ext.grid.EditorPanel and Ext.form.BasicForm
That's pretty much it.
Having said that, there are drawbacks to ExtJS.
You're going to have to get your hands dirty in the internals. Don't be beguiled by the demos.
The community documentation is poor and PHP-centric.
Coming from the Github/Lighthouse-centred RoR world, using VBulletin is like waking up in 1998. I mean, there's no public bugtracker just a forum post that's updated (WTF?).
The code is a bit over-engineered.
The team have lost Open Source credibility so they've lost Open Source oxygen.
The team appear to be focused integration with GWT (can anyone say "enterpri$ey"?).
You might want to have a look at the Netzke framework that is thought to do just that: facilitate creating complex one-page web-application with the emphasis on modular approach.
The advantages of Netzke are:
Reusability and extensibility of the code. Once you get your component (both client and server side) made, you can reuse it in any place, combine with other components, or event extend it with inheritance.
Efficiency. Class for every component is loaded from the server (and evaluated) only once, which saves a lot of time on server-client communication.
It's open source, and it's in active development. It has live demos and example code.
It has prebuilt components that you can use straight away without even touching Ext JS (just configure them in Rails)
It's been used (by its author) for real-life development of a complex logistics application.
Disadvantages of Netzke are:
The code is still young, and the community small.
If you're interested, have a look at the description and design details here: https://github.com/nomadcoder/netzke-core
Live demo/tutorials can be found here: http://netzke-demo.herokuapp.com and here: http://yanit.heroku.com
Ext is definitely mature enough to handle this situation. I'm currently working on a Rails project with a lot of Ext, and the hardest part has definitely been working with Rails's to_json to render JSON that Ext can read (for arrays, hashes, models, which failed validation, etc.)
Check out the ext_scaffold plugin for Rails. I started with this and hacked away at its ActiveRecord/ActionView extensions until it did what I needed it to do.
I has some experience using ExtJS with Rails too. Using the framework is a great way to get some nice looking widgets for free. REST convention should sit well with the framework too if you use it to develop single page applications. Works well with RJS too.
Here are my gripes with using the framework
You can't really make use of flash[:notice] since reloading a single page application is silly. This makes passing validation notices and messages a chore since you have to use RJS/ javascript methods to show them.
You can't use erb much thus you have to encapsulate a lot of the logic into the json callbacks.
I've deployed ExtJS and Rails for a number of applications and they certainly can be made to talk to each other. We've put together a quick demo of an app we're currently developing in Rails + Ext at http://demo.domine.co.uk/admin. Ignore the front end for now as it's not complete - the admin section is essentially finished and you can log in to it with:
username: edward
password: rarrar
As the demo's not completely finished yet I won't guarantee that it works correctly in anything other than Firefox at this stage. There's no reason for it not to work in other browsers, I just haven't spent any time testing them yet. The point is more about the integration with rails though.
Every application on the start menu is interacting with the Rails backend via JSON. I've written a basic Rails plugin to do most of the work for us there. I'll be releasing the code behind that shortly but for now hopefully that gives some idea of how well these two technologies can work together...
While I have no experience of ExtJS (besides reading about in the "Practical Rails Projects" book) I used a jQuery Flexigrid with jrails to get more of a desktop feel.
That worked pretty well.
Ok. I use extjs gxt gwt on many project, and it very easy for develop. But I want to tell you that I built my project with extjs+gwt (gxt), I don't sure about Ruby.
link text
Related
I've been using Ruby on Rails since a little more than one year now and I've always do it in a casual way, I mean, everything in one place (front & back), using the standard .html.erb file populated by the associated controller method.
Otherwise, today in our project, I have the need to separate the front and the back end for multiples reasons (code maintainability / clarity, better architecture, more reactivity, etc...).
I've done plenty of researches, watch some conferences (1, 2, 3), but didn't find my solution yet. It looks like to be a question that comes often, but what is the best practice/tools to separate the backend and the frontend of a Ruby on Rails app?
I don't feel we need (yet) a huge JS framework like React/EmberJS/Angular/etc...
First I was thinking about something like Middleman/Jekyll and make the communication via JSON and API calls, but it seems like that it's not a good solution for dynamic website.
So is there a frontend framework that works well with a Rails API and which is easily maintainable and upgradable (add feature/extension to it like gems)?
Thanks for your insights.
A friend of mine wrote this great article/tutorial on Rails as a backend API.
http://blog.launchacademy.com/the-basics-of-building-an-api-in-ruby-on-rails/
As well as this tutorial on Rails/Ember.js
https://github.com/diegodesouza/Project-Planner-EmberJS
You can get an idea of how it's done and implement your preferred front end framework.
Hope it sheds some light on this question.
I have a similar setup as one of the commenters on the question.
I'm using Rails mainly for just the project structure, to define some page layouts, and for ActiveRecord.
I then have my JSON APIs defined using the Grape API framework.
I have a SPA, written on AngularJS that lives in the public/ folder. It doubles as my mobile app, made possible by phonegap. If my Angular app didn't double as my mobile app, I could've possibly just used the asset pipeline to serve up the SPA. To compensate for that, I have a separate build task written in Grunt to minify/uglify my JS/CSS assets before I deploy them out to production.
I also use Comfortable Mexican Sofa for my static content pages.
It took some trial and error to get things right, but overall I find that this setup serves me pretty well.
We are planning to make a "large" website for I'd say 5000 up to many more users. We think of putting in lots of real time functionality, where data changes instantly propagate to all connected clients. New frameworks like Meteor and DerbyJS look really promising for this kind of stuff.
Now, I wonder if it is possible to do typical backend stuff like sending (bulk) emails, cleaning up the database, generating pdfs, etc. with those new frameworks. And in a way that is productive and doesn't suck. I also wonder how difficult it is to create complex forms with them. I got used to the convenient Rails view helpers and Ruby gems to handle those kind of things.
Meteor and DerbyJS are both quite new, so I do expect lots of functionality will be added in the near future. However, I also wonder if it might be a good idea to combine those frameworks with a "traditional" Rails app, that serves up certain complex pages which do not need realtime updates. And/or with a Rails or Sinatra app that provides an API to do the heavy backend processing. Those Rails apps could then access the same databases then the Meteor/DerbyJS app. Anyone thinks this is a good idea? Or rather not? Why?
It would be nice if anyone with sufficient experience with those new "single page app realtime" frameworks could comment on this. Where are they heading towards? Will they be able to handle "complete" web apps with authentication and backend processing? Will it be as productive/convenient to program with them as with Rails? Well, I guess no one can know that for sure yet ;-) Well, any thoughts, guesses and ideas are welcome!
For things like sending bulk emails and generating PDFs, Derby let's you simply use normal Node.js modules. npm now has over 10,000 packages, so there are packages for most things you might want to do on the server. Derby doesn't control your server, and it works on top of any normal Express server. You should probably stick with Node.js code as much as possible and not use Rails along with Derby. That is not to say that you can't send messages to a separate Rails app, but since you already have to have a Node.js app running to host Derby, you might as well use it for stuff like this.
To communicate with such server-side code, you can use Derby's model events. We are still exploring how this kind of code works and we don't have a lot of examples, but it is something that we will have a clear story around. We are building an app ourselves that communicates with an email server, so we should have some real experience with this pretty soon.
You can also just use a normal AJAX request or send a message over Socket.IO manually if you don't want to use the Derby model to do this kind of communication. You are free to make your own server-side only routes with Express along with your Derby app routes. We think it is nice to have this kind of flexibility in case there are any use cases that we didn't properly anticipate with the framework.
As far as creating forms goes, Derby has a very powerful templating system, and I am working on making it a lot better still. We are working on a new UI components feature that will make it possible to build libraries of self-contained UI widgets that can simply be dropped into a Derby app while still playing nicely with automatic view-model bindings and data syncing. Once this feature is completed, I think form component libraries will be written rather quickly.
We do expect to include all of the features needed for a normal app, much like Rails does. It won't look like Rails or work like Rails, but it will be similarly feature complete eventually.
For backend tasks (such as sending emails, cleaning up the database, generating pdfs) it's better to use resque or sidekiq
Now, I wonder if it is possible to do typical backend stuff like
sending (bulk) emails, cleaning up the database, generating pdfs, etc.
with those new frameworks. And in a way that is productive and doesn't
suck. I also wonder how difficult it is to create complex forms with
them. I got used to the convenient Rails view helpers and Ruby gems to
handle those kind of things.
Also, my question is not only about background jobs, but also about stuff one can might do during a request, like generating a pdf, or simply rendering complex views with rails helpers or code from gems. –
You're mixing metaphors here - a single page app is just a site where the content is loaded without doing a full page reload, be that a front end in pure js or you could use normal html and pjax.
The kind of things you are describing would be done in a background task regardless of the fornt-end framework you used. But +1 for sidekiq if you're using ruby.
As for notifying all the other users of things that have changed, you can look into using http://pusher.com or http://pubnub.com if you don't want to maintain a websocket server.
a friend of mine wants to create a simple inventory database that can be deployed on the web.
He has had a lot of experience with Database tools like Paradox. Moreover he has experience with writing Macros and programs with Basic, and even a bit of C++ experience. He uses Windows and Mac OS X, though mostly Windows.
If the requirement of having a web application wasn't there I would recommend MS Access.
Currently I see these options:
A) Ruby on Rails
Pros:
easy to start out (even on Windows?!)
at least from a programmers point of view perfect to create simple CRUD applications
can be deployed at virtually every popular Cloud hoster
I could easily assist if there were problems
Cons
ActiveRecord is from my point of view too technical
Designing forms requires ability to fiddle around with CSS and HTML
B) VB.Net
Pros
he has experience with simliar programming languages
easy to create forms and possible to deploy CRUD apps on the web
Cons
can be deployed only at few hosters (only Azure?)
simple problems can be quite difficult to solve in VisualBasic
C) Cold Fusion, ...?!
Pros/Cons
I have no idea
I am happy to hear about your suggestions.
Thanks, Philip
I have yet to use it, but the http://www.force.com/ platform (which salesforce.com is built upon I guess) is supposed to make it easy to develop data driven apps for more like business analyst roles. There is a cost to host it, but one app isn't that much on a monthly basis and the 30 day free trial would let you figure out if it worked for you or not.
If you are looking for database application frameworks for people who are not software developers, you might look at LightSwitch. It is designed for that particular demographic.
As much as I like Ruby on Rails AND the .Net platform for database-driven apps, they are both designed for developers to use. Going to something designed for your task might just be what your friend needs.
http://www.microsoft.com/visualstudio/en-us/lightswitch
Check out the examples on agiletoolkit, the php framework with jquery and php form examples. It's php with some jquery but to get a basic application up and running against a database, you dont need to know much php at all.
The five lines are the code shown on the left of the image are all thts needed to create a CRUD based on a database table with both a form and a grid with specified columns. It will open a jquery dialog for ADD and EDIT and uses AJAX to update the form.
It also has built in functionality to add one click sorting on the column headings, pagination so you dont get an endless grid on one page but get << < 1 2 3 .. N > >> style links to page through the results set and a search box to filter the results to a specified subset.
Note the colours are added by CSS and can be removed.
The second negative point for Rails ("Designing forms requires ability to fiddle around with CSS and HTML") could be easily mitigated with the use of a gem that generates forms (like formtastic or simple_form).
Apart from Rails I would suggest Monk which is a lighter-than-rails ruby-based web framework. Its components are loosely held together and there are many skeletons (web app templates) to choose from.
Pros
multiple skeletons to choose from
very light/minimal (a new developer will not get lost in the myriad of files and folders that Rails is)
as easy to deploy as Rails (is rack based)
Cons
does not seem to be as well-maintained as Rails
most Ruby stuff don't play well in Windows (AFAIK)
PS: on the second positive bullet of rails (and ruby) I would like to add Heroku which is a GREAT service for getting-started projects.
Building CRUD Apps using ZK Studio is very easy.
CRUD Apps can be built in 5 to 6 steps. Check it out.
Rails is the most innovative and easy approach to creating crud apps ever.
There are plugins like active_scaffold and hobo that allow you to create CRUD apps without having to write almost any code.
This is a bit of a weird meta-programming question, but I've realized that my new project doesn't need a full MVC framework, and being a rails guy, I'm not sure what to use now.
To give you a gist of the necessary functionality; this website will display static pages, but users will be able to log in and 'edit their current plans'. All purchasing and credit card editing is being handled by a recurring payment subscriber, I just need a page to edit their current plan. All of that will be done through (dynamic) XML API calls, so no database is necessary.
Should I stick with my typical rails/nginx stack, or is there something I could use that would lighten the load, since I don't need the Rails heft. I'm familiar with python and PHP but would prefer not to go that route. Is Sinatra a good choice here?
tl;dr: What's a good way to quickly serve mostly static pages, preferably in Ruby, with some pages requiring dynamic XML rendering?
If you want to stick with Ruby, Sinatra would be fine, as would Rails Metal.
If you're feeling a bit adventurous and want to get some useful experience with the technology that rails uses you could try building a Rack application. It's a pretty simple API to be able to respond to generic HTTP queries, and from there you can quickly build static file handling and XML processing. It's also considerably faster to start up and serve pages than rails.
http://github.com/cloudhead/toto is an example of a decent Rack based application.
If you know Rails, then why not just stick with it? That way you can use all authentication features, etc. that you're used to without having to learn another platform and incur the implementation risks that that includes. If the application ever grows beyond what's expected you're already on a solid base.
I've recently started working with RoR for some projects and I quite like the framework - however coming from an ASP.NET background I'm quite fond of the idea of being able to purchase & drop in reusable components/control such as those from telerik, without having to 'reinvent'.
I suppose it would be possible to maybe create my own using partials or plugins or similar, but I'm wondering if there is anything out there already, or perhaps alternatives which could be massaged into place, like javascript widgets etc?
I don't know of any commercial components or "controls", but there's thousands (probably, I haven't counted them) of plugins out there freely available, to do a great many things for you, some of which would probably count as "controls". Unfortunately, there's no one place to go and find them, and the quality is depressingly variable, but there are a number of plugin indexes like http://agilewebdevelopment.com/plugins/ that might help in finding what you want while weeding out the dross.
Ext JS is a great GUI toolkit. I can't say that it entirely fits in with the RoR way of doing things, but if you write your controllers to return JSON it isn't too bad.
One of the big differences between Ruby/Rails and the .Net world is the fact that most of the available plugins are open-source and integrate at the code level. There is an incredible array of plugins for Rails, and it is very straight forward to write your own. Due to the nature of Ruby you can hook into any just about any part of the language and framework, giving you impressive extensibility.
I am not sure how Web Controls work, but it sounds like they are a "black-box" that provides an end-to-end solution for both UI and data-level operations ... ?
Many of the Rails plugins do provide both UI and data aspects. An example would be "restful_authentication" which provides you with both some basic forms for login and user registration as well as an authentication module and a Active-Record model. Again, this operates at a code-level, so will actually push the relevant code into your codebase when you install and "generate" the authentication modules.
As for "widgets", there is no equivalent in Rails, per-se, but there are a number of JavaScript libraries that provide similar functionality. I use and recommend jQuery UI, myself.
Dojo has a widget library which might meet your needs.