I am using Ruby on Rails and I heard of “Unobtrusive JavaScript” (UJS). After (but even before) my previous question, I ask myself:
Are there common-used patterns, rules, practices or techniques in order to respond pragmatically to JavaScript and HTML AJAX requests? If there are, what are those? For example, what responses should be returned? What kind of data? Is there a standard?
Practically speaking, how should my controller respond_to (à la Rails) depend on the request format? That is, how should my application respond with format.js, format.html or format.whatever in controllers when using the Rails framework?
About the previous matters, what is the solution of the Rails community and / or of the “general” public? What do you use?
Ajax
I don't know any patterns, but we take a "per feature" stance -
You'll have different use cases for different features. In the most part, you can handle these using the remote: true option (which just uses the ajax handler in UJS), which will allow you to either capture the response with .on("ajax:success" in your asset JS, or by using a .js.erb file in the backend
The bottom line is we do what will produce the least amount of code. We always look at it from the perspective of future development - in the future, will you get confused with what we're doing, or will it be the logical way?
I suppose we could probably find a more structured way of handling this, but with the varying amounts of data coming back, we prefer to handle each feature in its own way
--
Code
I would personally put code efficiency & focus functionality first
Instead of trying to make a pattern to fit all cases, I'd look at what you're trying to achieve, and creating code to get it to work. If you can refactor after that, great! Otherwise, I'd invest my energy into getting functionality working
Related
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.
I have a Rails app where I load up a base HTML layout and I fill in the main content with rows of divs from JSON. This works in 2 steps:
Render the HTML
Ajax call to get the JSON
This has the benefit of being able to cache the HTML layout which doesn't change much, but it seems to have more drawbacks:
2 HTTP requests
HTML isn't that complex, the generated html is where all the work is done, so I'm not saving that much on time probably.
Each request in my specific case requires that we check the current user, their roles, and some things related to that user, so those 2 calls are somewhat involved.
Granted, memcached will probably solve a lot of this, I am wondering if there are some best practices here. I'm thinking I could do this:
Render the first page of JSON inline, in a script block, along with the HTML. This would cut out those 2 server calls requiring user authentication. And, assuming 80% of the time you don't need to make the second ajax call (pagination/sorting in this case), that seems like a fairly good solution.
What are your thoughts on how to approach this?
There are advantages and disadvantages to doing stuff like this. In general I'd say it's only a good idea, if whatever you're delaying via an ajax call would delay the page load enough to annoy the end user for most of the use cases on your page.
A good example of this is browsing a repository on github. 90% of the time all you want is to navigate the files, so they use an ajax load to fill in the commit messages per file after the page load.
It sounds like you're trying to do this to speed up or do something fancy for your users, but I think you should consider instead, what part is slow, and what speed of page load (and maybe for what information on that page) on your users are expecting. As you say, using memcached or fragment caching might well give you the improvements you're looking for.
Are you using some kind of monitoring tool? I'm using the free version of New Relic RPM on Heroku. It gives a lot of data on request times for individual controller actions. Data like that could help you focus your optimization process.
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 have been spending some time creating what I called a framework.
It was aimed at the creation of quiz likes games. It was supposed to have two players syncronized and present them a question to solve, etc.
I would like it to be fully customizable so I tried to develop components that can be put in or out of the pages. In the end the elements became slim ruby methods to add a whole bunch of Javascript and CSS to the pages.
Still the Javascript needs to connect to Ruby so methods supporting it are created but they will only be present when the component is present. Some components depend on one another making everything overly complex.
And after this attempt I wonder, is there is not a better and easier way to make a framework aimed to one kind of application on RoR? Or is the concept flawed or RoR in some way flawed?
Ruby on Rails is a framework on its own accord and is "opinionated software". This means that the writers of Rails looked at what would make most sense for creating a web application to them. Many people support the original developers views and so use Rails for their projects as well.
I think your concept of creating a quiz is a good one, but first you need to understand the rails stack. Depending on what you need exactly, you can create either an engine, plugin or whatever.
What I have seen a lot is that you specify what you need in your controller. (How you do that is up to you). All that information is stored in a class variable and transferred to the view where you can render everything you need with some helpers. The hard part is making it all generic enough to be reusable.
But, maybe Rails isn't the right tool for you. Maybe you need something more lightweight like Merb or even Sinatra.
There is no 'flaw' in Rails. Rails is not the 10**1000-in-one tool Java is. It's a framework that tries to do one way very good in a particular way. I think Rails can be the right tool for you, but you need to be skilled enough to wield the tool :)
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