Представления Rails3 - структура каталогов шаблонов JS

Мне очень не нравится дублировать структуру каталогов в общей папке, чтобы содержать шаблоны Javascript, как это предлагается здесь. Я собираюсь погрузиться в проект. Любой, кто может отговорить меня от добавления всех моих JS-представлений к другим моим представлениям, пожалуйста, объясните причины, по которым этого не делать. Мои мысли:

Используете ли вы шаблоны Backbone, Jammit или любой другой Javascript для создания представления ваших данных, не должен ли этот код в идеале находиться в каталоге /app/views/[object]? Если мы разрабатываем приложение с несколькими способами представления данных, разве все эти представления не должны находиться в одном месте?

Конечно, не имеет смысла настраивать маршруты и заставлять рельсы обслуживать файлы, но если мы используем Jammit/Closure/другой инструмент сжатия JS, то мы уже добавили слой обработки между нашей структурой каталогов и JS. мы передаем клиенту. Разве это не означает, что мы можем размещать шаблоны там, где это наиболее целесообразно для организации/обслуживания кода?

Спасибо.


javascript model-view-controller ruby-on-rails-3 backbone.js jammit
person RSG    schedule 06.04.2011    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Причина, по которой файлы .js не рекомендуется помещать в app/views/[object], заключается в том, что они не являются частью приложения Rails. На самом деле они являются частью приложения/фреймворка Backbone или Jammit, поэтому они не принадлежат каталогу приложений. Если бы файлы были файлами .js.erb, то они должны были бы находиться в каталоге приложения, но поскольку это не так, они принадлежат каталогу public/javascripts.

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

Имейте в виду, что если они находятся в каталоге /app/views, их нужно будет обслуживать через Rails. Другими словами, вам потребуется сервер-контроллер, а это добавляет дополнительную сложность и нагрузку на ваши серверы. Более того, если они не требуют передачи рубиновых данных от ваших контроллеров к представлениям, у вас будут довольно простые/бессмысленные контроллеры, которые просто обслуживают статические данные. И вам, вероятно, придется переименовать файлы в .js.erb, чтобы их можно было обслуживать через эти контроллеры. Если файлы обслуживаются непосредственно из общедоступного каталога, в этом нет необходимости, так что это намного проще.

Нет ничего плохого в том, что один каталог дублирует другой, это часто случается, например, с RSpec spec/models, spec/views, spec/controllers.

person Pan Thomakos    schedule 06.04.2011
comment
Конечно, есть основные файлы фреймворка, но цель фреймворка — позволить вам создавать javascript-представления объектов вашего приложения. Разве они не должны быть частью приложения Rails? - person RSG; 07.04.2011
comment
Я обновил свой ответ дополнительной информацией, которая может помочь прояснить это. - person Pan Thomakos; 07.04.2011
comment
Спасибо. Инструменты сжатия JS «скомпилируют» все JS из каталога rails в общедоступный каталог, поэтому нет необходимости создавать маршруты или добавлять .erb в файлы JS. Мне, наверное, просто нужно бить по голове этим последним предложением, пока оно не перестанет меня беспокоить :) - person RSG; 07.04.2011
comment
В этом есть смысл, но если файлы все равно будут перемещены в общий доступ, почему бы просто не оставить их там? Опять же, вы всегда можете структурировать свои каталоги так, как вам больше всего подходит, если ваш метод последователен, и остальные ваши товарищи по команде согласны с ним :) - person Pan Thomakos; 07.04.2011