проблемы с form_tag для действия контроллера с маршрутом получения участников

I ' m создание панели form_tag, содержащей информацию (флажки), относящуюся к действию контроллера. Это действие настраивается в "routes.rb" следующим образом:

resources :students do
  collection do
    get :send_student_report_pdf
  end   
end

Эта настройка отлично работает , когда я вызываю действие из link_to:

<%= link_to "Download PDF Report", :action => 'send_student_report_pdf', :controller => 'students'%>

Однако, когда я использовал его в form_tag , он продолжает выдавать мне эту ошибку:

Routing Error
No route matches "/students/send_student_report_pdf"

Код form_tag , который у меня есть, находится здесь:

<%= form_tag :controller => 'students', :action => 'send_student_report_pdf', :method => 'get' do %>
  <%= label_tag "Include columns" %> 

  <%= check_box_tag "first_name", params[:first_name], checked = true %> <%= label_tag "First Name" %>
  
  <%= submit_tag "Download PDF Report", :action => 'send_student_report_pdf', :controller => 'students'%>  
<% end %>

Я попытался указать ему URL-адрес, например:

<%= form_tag send_student_report_pdf_students_path, :method => 'get' do %>

Но он постоянно дает мне ту же ошибку Route (как будто действия вообще не существует в routes.rb, хотя он отлично работает с использованием link_to вместо form_tag submit

Вот код для действия в контроллере, он в основном отправляет обратно файл.

def send_student_report_pdf
  @students = search_sort_and_paginate
  puts "params[:first_name] = ", params[:first_namea]
  send_data(generate_pdf_report(@students), :filename => "report.pdf", :type => 'application/pdf') 
end

Если вы видите, что мне здесь что-то не хватает, пожалуйста, помогите мне.

Большое спасибо, jquery.tmpl и т. д.

Теперь проблема в кэшировании и удобстве сопровождения.

С одной стороны, я думаю, что если бы все было построено с использованием HTML-шаблонов Javascript, то мое приложение могло бы обслуживать только HTML-макет / оболочку и еще несколько JSON. Если вы посмотрите на исходный код HTML в Facebook и Twitter, то в основном это то, что они делают (95% json / javascript, 5% html). Это сделает так, что моему приложению нужно только кэшировать JSON (страницы, действия и / или записи). Это означает, что вы попадете в кеш независимо от того, были ли вы каким-то удаленным разработчиком api, обращающимся к JSON api, или простым веб-приложением. То есть мне не нужны 2 кеша, один для JSON, один для HTML. Похоже, это уменьшило бы объем моего кеш-хранилища вдвое и немного упростило бы работу.

С другой стороны, я думаю, из того, что я видел / испытал, генерируя статический HTML на стороне сервера, и кеширование, которое кажется намного более эффективным с точки зрения кроссбраузерности; вы получаете графику мгновенно и не должны ждать доли секунды, пока javascript отобразит ее. StackOverflow, кажется, делает все в обычном HTML, как и Google, и вы можете сказать ... все появляется сразу. Обратите внимание на то, что на twitter.com страница остается пустой в течение 0,5–1 секунды, а страница разбивается на части: javascript должен отображать json. Обратной стороной этого является то, что для чего-либо динамического (например, бесконечной прокрутки или сетки) мне все равно придется создавать шаблоны javascript ... так что теперь у меня есть шаблоны HAML на стороне сервера, клиентские шаблоны javascript и многое другое для кеширования.

Мой вопрос: есть ли консенсус относительно того, как к этому подойти? В чем заключаются преимущества и недостатки вашего опыта смешивания этих двух методов по сравнению с использованием 100% одного по сравнению с другим?

Обновление:

Некоторые причины, которые влияют на то, почему я еще не принял решение использовать 100% Шаблоны javascript:

• Производительность . Официально не тестировался, но, судя по тому, что я видел, необработанный html отображается быстрее и плавнее, чем кроссбраузерный HTML, созданный с помощью javascript. Кроме того, я не уверен, как мобильные устройства обрабатывают динамический HTML с точки зрения производительности.
• Тестирование . У меня есть много интеграционных тестов, которые хорошо работают со статическим HTML, поэтому переход на использование только javascript потребует 1) более целенаправленного тестирования чистого javascript ( jasmine ), и 2) интеграция javascript в интеграционные тесты capybara. Это всего лишь вопрос времени и работы, но, вероятно, значительный.
• Техническое обслуживание . Избавляемся от HAML. Я люблю HAML, его так легко писать, он печатает красивый HTML ... Он делает код чистым, упрощает обслуживание. Используя javascript, нет ничего более лаконичного.
• SEO . Я знаю, что Google обрабатывает ajax / #! / Path , но не понял, как это повлияет на другие поисковые системы и как старые браузеры обрабатывают это. Похоже, это потребует значительной настройки.