If you don’t use JS templates and still manipulate the DOM of your page to fill in data from a JSON object, you’re just doing it wrong :).

There are lots of templating plugins available in JavaScript like jquery-tmpl, or even the template method from the great Underscore.js library.

But what is the easiest solution to reuse view partials between the Rails application and the JavaScript code? Often I have to display a partial statically in my view using a render call with some Ruby objects and render the same partial in JavaScript. I don’t want to maintain 2 versions of my partial.

After looking and testing many different solutions, one of the easiest is to use Mustache, a Rails gem plugin called Stache and ICanHaz.js.

Here is a Rails 3.1 example which provides a simple user partial.
This partial is used in the UsersController index action to display the first users.
Then it is reused in JavaScript in an AJAX pagination by fetching the next users in JSON.

When rendering the Mustache partial, we send it all the attributes of the user, so we don’t have to build a long Hash manually.
Notice the template_include_tag call. This helper is provided by Stache and directly puts the partial raw code in the view, so that we’ll be able to use it in JavaScript.

Next we’ll write the Load next button behavior in CoffeeScript which will fetch the next users then use the Mustache partial to render them.
Thanks to ICanHaz, we can render the user partial in just… one line of code!

]]>https://slainer68.wordpress.com/2011/09/20/partial-reuse-between-rails-js-the-easy-way/feed/1slainer68You should already use CoffeeScript in your Rails app!https://slainer68.wordpress.com/2010/12/13/you-should-already-use-coffeescript-in-your-rails-app/
https://slainer68.wordpress.com/2010/12/13/you-should-already-use-coffeescript-in-your-rails-app/#commentsMon, 13 Dec 2010 16:12:18 +0000http://blog.nicolasblanco.fr/?p=67In the latest weeks, I had to write some Javascript at work and I decided to evaluate CoffeeScript.

As you may know, CoffeeScript is a language written in Javascript that compiles into… Javascript. But it has a great syntax that takes some great ideas from Ruby and Python.
If you want to discover CoffeeScript, just go through this great presentation.

I wanted to know if it is now possible and a good thing to use CoffeeScript in a production Rails application.
After some evaluations I decided that I’ll use CoffeeScript to develop my next JavaSript code. Here is why…

The most important thing is that CoffeeScript compiles into readable JavaScript. You can open your ‘compiled’ Javascript and clearly understand the code, ie. : it does not change your variables names or function names or add a lot of garbage code… So if one day I decide to stop using CoffeeScript for whatever reason, I’ll still be able to work and go on on the compiled script directly.

IMHO, the Rails gems to integrate CoffeeScript into a Rails app are know mature and work very well.

If you have never used CoffeeScript before you may want to know if it’s possible to use CoffeeScript with your existing JS librairies (jQuery, etc.), to mix JS code with CoffeeScript code, etc… And of course, it’s possible and very easy ! So you should really give it a try.

How to use CoffeeScript in your Rails application?

It’s really easy.Barista is the Rails gem that will take care of your CoffeeScript files and compiles them into JavaScript when you request them in your application.

The latest versions of Barista depends on the coffee-script gem. This gem only auto-detects the available compilers on your computer as there are several ways to install CoffeeScript. You may choose to follow the official documentation and install it using node.js, but if you don’t want to setup node.js, you can use the therubyracer gem and you won’t have to install anything else!
therubyracer includes V8 (the fast Javascript engine from Google).

Finally the coffee-script gem depends on the coffee-script-source gem. This gem only contains the CoffeeScript source code and it is synced with official releases. Thanks to this gem, you can lock your application to a particular CoffeeScript version.

So, this was a great explanation speech… But in summary, if you want a fast way to include CoffeeScript in your Rails app, here is what you have to add to your Gemfile :

gem 'therubyracer', :require => false
gem 'barista', '0.7.0.pre3'

Then you may run :

rails generate barista:install

this will generate the initializer config/initializers/barista_config.rb which you may edit to change the Barista configuration.
As I’m using SASS/SCSS which compiles from app/stylesheets to public/stylesheets/compiled, I thought that a cool configuration would be to let Barista compiles my CoffeeScript into public/javascripts/compiled :-).

Add javascript_include_tag « compiled/hello » to one of your view and check that everything works!
Congrats! Now, a good idea would be to let Barista and Coffee in your app and write your next JS code in Coffee…
Barista will detect changes in your CoffeeScript files and compiles them after each request to your webserver (only in development environment).

To avoid writing compiled/ in front of all my compiled scripts, I added this simple helper to my project :

Now for the deployment part. You may version the CoffeeScript compiled files…
But I prefer to ignore them and to lock the project to a specific coffee-script-source gem version. That will ensure that all the developers work with the same CoffeeScript version.

Then I use the barista:brew rake task in my Capistrano file using an after hook.
This rake task will just compile all the CoffeeScript source files during deployment. So you can safely pack them using your prefered asset packager after compilation…

Now, have a coffee!

]]>https://slainer68.wordpress.com/2010/12/13/you-should-already-use-coffeescript-in-your-rails-app/feed/3slainer68Quick and simple geocoding without external librairieshttps://slainer68.wordpress.com/2010/09/29/quick-and-simple-geocoding/
https://slainer68.wordpress.com/2010/09/29/quick-and-simple-geocoding/#commentsTue, 28 Sep 2010 23:47:18 +0000http://blog.nicolasblanco.fr/?p=57When you want to implement geocoding for one of your Ruby on Rails models, the first thing you may do is to include the good old geokit gem…

But do you know that if you just want to retrieve and store lat/lng in your records, geokit or another external library is unnecessary ?
And moreover, geokit still uses the old Google Maps API v2… Google has updated his Maps API (v3) and it is very easy to consume it using simple GET calls returning JSON. And, icing on the cake : Google API v3 does not require an API key! So no more headache managing multiple API keys for all your environments…

Here is a small example (geocode the street field). This is a Mongoid model, but of course it would work with ActiveRecord or anything else…

]]>https://slainer68.wordpress.com/2010/09/29/quick-and-simple-geocoding/feed/6slainer68Rails 3, HTML 5 and client-side forms validations using Validatorhttps://slainer68.wordpress.com/2010/09/02/rails-3-html-5-and-client-side-forms-validations-using-validator/
https://slainer68.wordpress.com/2010/09/02/rails-3-html-5-and-client-side-forms-validations-using-validator/#commentsThu, 02 Sep 2010 15:59:51 +0000http://blog.nicolasblanco.fr/?p=26There are many client-side JS forms validations librairies available on the Internet. There are also many Rails plugins and FormBuilders gems.
While working on a new project using Rails 3, I wanted to find an easy way to validate my forms client-side using JS. I also usually don’t use plugins like Formtastic, I prefer writing my own custom FormBuilder for each project in collaboration with the webdesigner…

I found Validator by the flowplayer team. This Javascript library is just great. Why? Because it uses some HTML 5 new attributes to define validations on the form inputs. And guess what? It works perfectly with the new Rails 3 HTML 5 helpers.
You can just map this library on all your <form> tags in your application.js, use some HTML 5 attributes and get instant and unobtrusive client-side validations.

Alongside email_field, there are other HTML 5 helpers that are included by default in Rails 3 : number_field, range_field, search_field, telephone_field, url_field, see the ActionView::Helpers::FormHelper API for more information about these new helpers.

Of course you cannot do complex validations or validations that require a server-side callback (like uniqueness validations) only by using HTML 5 attributes. But IMHO, the few attributes used by Validator are really a good start if you want something light and don’t want to use some bloated library or plugin. Take a look at the Validator documentation to see all the attributes and advanced options you can use (i18n is also possible!).

And… One more thing ! I wrote a simple module that easily integrates with any custom FormBuilder. It does simple reflection on the current model instance to automaticaly set some HTML 5 attributes. Here it is…

As you can see for now, it just returns a default options hash with the required and min/max attribute (if the model instance class has validates_presence_of or validates_inclusion_of with a Range).
At first, I also wanted to add the pattern attribute if a validates_format_of is used, but unfortunately the Ruby and JS regexps are often different… I did not find an easy way to reuse them directly (if you find a workaround, tell me :-)).

Then, in your FormBuilder, just use the module to get the default options hash :

]]>https://slainer68.wordpress.com/2010/09/02/rails-3-html-5-and-client-side-forms-validations-using-validator/feed/7slainer68Easy « paranoid » with Rails 3 and state_machinehttps://slainer68.wordpress.com/2010/08/25/easy-paranoid-with-rails-3-and-state_machine/
https://slainer68.wordpress.com/2010/08/25/easy-paranoid-with-rails-3-and-state_machine/#commentsWed, 25 Aug 2010 08:59:18 +0000http://blog.nicolasblanco.fr/?p=19Do you remember the good old « acts_as_paranoid » plugin for Rails? The bahaviour of the plugin is simple : you want to « soft »-delete the records in your database.

When your users use your app to destroy a record, they don’t see it anymore, but the record is still kept in the database for security purposes.

Since the latest versions of Rails 2 it’s been very easy to implement this kind of behaviour using default_scope. With Rails 3, the state_machine gem and the « unscoped » method the syntax is even nicer!

]]>https://slainer68.wordpress.com/2010/08/25/easy-paranoid-with-rails-3-and-state_machine/feed/5slainer68Capistrano task for Bundler 1.0https://slainer68.wordpress.com/2010/07/30/capistrano-task-for-bundler-1-0/
https://slainer68.wordpress.com/2010/07/30/capistrano-task-for-bundler-1-0/#commentsFri, 30 Jul 2010 09:18:53 +0000http://blog.nicolasblanco.fr/?p=9UPDATE ! In case you don’t know : there is now a Capistrano task integrated in Bundler (see it there). So if your needs are basic, you may use it instead of writing your own.

4 august 2010 : updated for Bundler 1.0rc3. –production option is now called –deployment to avoid confusion with some common groups names :).

A new Bundler version (1.0rc3) has been released!

Now it includes a new option named –deployment to isolate the gems.

This is the option you need to use in your deployment tasks. Here is my new Capistrano task to deploy using Bundler 1.0rc3. I will update it until the final version arrive…