2014-09-24 2 views
0

Я смущен о запросе ajax в рельсах.Рельсы и ajax: путаница о обратном вызове

Я представляю форму, используя ajax, и все в порядке. Теперь я должен обрабатывать обратный вызов, но ...

После некоторых учебников Намек добавить

respond_to do |format| 
    format.js 
end 

в Controler # создать, а затем поместить в папку с видом «create.js.erb» с ответ.

Другие учебники предлагают создать файл js в папке с ресурсами и обработать обратный вызов из JS-файла.

В чем разница? И каков правильный путь?

+0

Что именно должен делать этот обратный вызов? –

+0

Это зависит ... например, мне нужно очистить поля ввода формы или мне нужно выполнить действие контроллера. Мне просто нужно знать, каковы различия между этими двумя методами! –

ответ

0

Оба варианта - это разные способы обработки обратного вызова запроса Ajax. Я предлагаю вам использовать файл js.erb для обработки обратного вызова ajax, потому что этот файл может распознать как JS, так и Ruby-код и выполнить.

Например,

в контроллере,

def create 

...

if something 
    @foo = true 
    else 
    @foo = false 
    end 

в вашем create.js.erb, это может быть сделано, как вы хотите, чтобы показать/скрыть некоторые div на основании значения @foo, вы можете написать, например,

<% if @foo %> 
    // do something with JS code 
<% else %> 
// do something else 
<% end %> 

Хотя, если вы создаете файл JS в папке с ресурсами, вы не сможете написать условие, как указано выше, потому что это чистый JS-файл, а создание js.erb - это простой способ обработки ответа ajax.

0

Это два разных подхода. Например, предположим, что все, что вы хотите сделать, - это отобразить сообщение, подтверждающее представление пользователя. Если вы идете вниз маршрут create.js.erb то, что файл может выглядеть как

$('#message').text('<%= j @message %>') 

Отклик на ваш Ajax запроса является немного JavaScript, который делает необходимые изменения в пользовательский интерфейс. jQuery выполняет этот javascript, когда он его получает, и ваш javascript не имеет никакой видимости того, что может сделать ответ.

Другой подход был бы для вашего контроллера просто отображать некоторые данные. Это может быть либо JSON, описывающий результаты представления, либо блок html. Например ваш контроллер может сделать

render json: {status: 'success', message: 'Thank you for your submission'} 

яваскрипта сделать XHR может выглядеть

$.ajax('/some_url', {dataType: 'json'}).done(function(data){ 
    //data is the json your controller sent 
    $('#message').text data.message 
}); 

или если вы рендеринга HTML

$.ajax('/some_url', {dataType: 'html'}).done(function(data){ 
    //data is the html your controller sent 
    $('#message').html data 
}); 

Так что в данном случае это ваш Javascript, который решает что делать с возвращаемыми данными.

Лично мне не нравится create.js.erb route - я считаю, что это делает мой javascript труднее читать: я не могу сказать, глядя на мой код представления формы, что может/может произойти в этом обратном вызове.

Также намного сложнее проверить, производят ли контроллеры что-то, что необходимо выполнить на другом языке, и гораздо сложнее проверить ваш javascript, если есть места, где он выполняет произвольный код, отправленный ему.

Я предпочитаю, чтобы он вел себя как api, возвращая структурированные данные, что клиент может действовать соответствующим образом (клиент может даже не быть браузером все время, это может быть мобильное приложение).

+0

Значит, это же право? –

+0

Нет, они совершенно разные, хотя в целом вы можете добиться того же самого –

Смежные вопросы