Does not play nice with x-editable

[mlt]

While best_in_place works more or less, it would be nice to make x-editable integrate tightly. There are few things that need to go in place as of now.

1. It would be nice if tabulatr triggered some event once table is rendered. This is necessary to trigger $('.editable').editable();. Perhaps $('#'+this.id).trigger('tabulatr:response'); somewhere here will do it.

2. I was able to use inline only method with $.fn.editable.defaults.mode = 'inline' as I get JS error otherwise. This however distorts table in weird way, namely, td is wider that span inside. It somewhat can be mitigated with

   table.tabulatr_table {
   table-layout: fixed;
   }

   Loading tooltip & popover plugins for bootstrap resolves popup issue.

3. Each block in data proxy need to contain xeditable? definition as required by x-editable-rails. AFAIK we neither can include stuff into a block nor to expect anything from instance_exec :( I wonder if an issue should be filed against x-editable-rails.

[mlt]

I propose to add another param hash editable to columns and associations to DRY up user code. Since fancy formatting may take place, we can't use editable as provided by x-editable-rails directly, however nothing prevents us from using an underlying x-editable. I think we can keep it simple. If editable: true, then just wrap val from value_for into a span with editable class and fire event upon ajax data. In more advanced case, we'd need to add data- stuff from editable hash param. I'm not so certain how to go about permission control. Either one has to explicitly evaluate editable to false/nil, or allow somehow a function to be passed so that Tabulatr::Renderer::Column (?) can call that function passing it model and column names to see if editing is allowed. I'm also not so sure how to go about urls for updates if those can't be deduced from a record, e.g. custom controller/action name. One would usually use _path helper for each individual record (as an argument).