How many times do you heard you should separate content from behavior? Never? Hmmm don’t try to cheat me.. So, why do you still use :confirm option for link_to helper?

Here a little snippet to archive our goal, and as extra bonus, you get it i18n:


<script type="text/javascript">
window._authenticity_token = "";
</script>

t(:’asset.destroy’),
:class => “delete”,
:’data-confirm’ => t(:’asset.destroy_confirm’) %>


$(document).ready(function(){
$(".delete").bind("click", function() {
if(window.confirm($(this).attr("data-confirm"))) {
$.ajax({
url: $(element).attr("href"),
data: {
_method: "delete",
authenticity_token: window._authenticity_token
},
type: 'post',
dataType: 'script'
});
}
return false;
});
});


For all of you who don’t know what I’m talking about, **Click to Globalize** is a Rails plugin for in-place translations. Now it’s compatible with Rails 2.3 and It’s also the most clean and polish version of ever, let me explain what’s changed.

Engine

Yes, **Click to Globalize** is now an [engine](http://rails-engines.org/), this means all the controllers, the helpers, the routes and the other stuff, now lives in `vendor/plugins`. No more clutter with flying files, except for one javascript and one stylesheet.

I18n

The [i18n team](http://i18n-rails.org/) (myself included) worked hard to build a **consistent API** for i18n. Starting from Rails 2.2 we have bundled a gem for this purpose, and now my plugin is totally compliant with this system, this **agnosticism** allow you to use whatever i18n backend you want. Click to Globalize is **no longer a Globalize extension!!**

RESTful

The plugin now bundles two **full RESTful** controllers: `TranslationsController` and `LocalesController`, respectively `/translations` and `/locales`.

Lightweight

I replaced the annoying `around_filter` system, with a more lightweight one, based on the observation of `ActionView#render`.

Formatting

I removed the support for **Markdown** and **Textile**, personally I never used so much, and don’t think they are so related with i18n.

Deprecations

The old `globalize?` method is deprecated in favor of `in_place_translations?`.

You can find all the new instructions to the [project page](http://lucaguidi.com/projects/click-to-globalize) or on [GitHub](http://github.com/jodosha/click-to-globalize).
Enjoy!

There are many dark corners and hidden features in a big framework like **Rails**.

Digging inside the code of **ActiveRecord** I discovered an interesting class: **SqlBypass**. When you set your session store on ActiveRecord it will use a **Base** subclass for deal with database store. This configuration adds an useless overhead for your application, because each session read/write will go through the complex callbacks system of ActiveRecord.

For these reason is highly advisable to use **SqlBypass**. As the name suggest it bypasses all the callbacks and simply performs read/write operations.

I created a patch for run engine’s migrations

~

I created a patch for run engine’s migrations, it adds two Rake tasks:

• db:migrate:engines
• db:migrate:engines:down

The first one allows to run all the migrations stored in the db/migrate directory of each plugin. It runs migrations in the same order Rails::Initializer register the plugins, this means if you force an order by environment.rb, it will be reflected on migrations order.

Example: You have four plugins in your app: apple, bar, foo, pear.