Как много логики вы вкладываете в представления?

Question

Я в настоящее время не уверен, могу ли я представить себе конструкцию "если / еще"?

Как много логики ты вкладываешь в свои взгляды?

Моя дилемма:

Я рендеринг навигации. Итак, я должен отличаться между текущим / активным пунктом меню и остальным. Текущий пункт меню получает специальный класс CSS. Я не знаю, как справиться с этим лучше, чем использовать if-else.

Answer 1

Если вы делаете MVC (надеюсь, вы делаете), тогда возникает вопрос: «Я помещаю логику в представление или контроллер?». Я использую простое правило, чтобы узнать ответ:

Что если бы мой взгляд был не HTML, а документ XML? Если мне понадобится эта логика в обоих обстоятельствах - ее место в контроллере. Если нет - это в поле зрения.

В хорошем дизайне MVC вы можете менять местами, не касаясь контроллера.

Answer 2

Столько, сколько необходимо для отображения информации. Просто помните, что представление - это просто окно во внутреннее состояние программы. Если вы полностью удалили слой представления, программа все равно должна работать как обычно, просто не видя, что она делает.

edit: повторяйте навигацию, это выглядит как правильное использование оператора if. Информация о том, что активно, все еще поступает из модели, вы просто используете оператор if, чтобы решить, как его отобразить. Вы могли бы немного подумать о том, как вы отображаете навигацию: доступна ли информация о том, какие элементы навигации доступны, а какие визуализируются в вашем представлении или модели?

Один из способов, с помощью которого вы можете выбрать подход к ситуации, состоит в том, чтобы модель дала вам список элементов навигации, вместе с тем, какой из них активен, и запрограммируйте представление, чтобы знать, как генерировать соответствующий HTML из этого. Этот код может содержать ровно один оператор if. (вместо одного для каждого элемента навигации).

Answer 3

Добавьте этот помощник в application_helpers.rb. Ваши ссылки будут окружены <li> и <li class="active">, если ссылка является текущей страницей.

Используйте его вместо ссылки.

link_to 'home', root_url, optional_condition_argument_goes_here

def active_link_to(text, url, condition = nil)
  if condition.nil? and String === url
    condition = url == request.path
  end
  content_tag :li, link_to(text, url), :class => (condition && 'active')
end

(Предоставлено Мислав )

Answer 4

Конструкция "if / else" хороша, если вид чередуется, например, форматирование адреса США против иностранного адреса на экране заказа.

Однако любая логика, которую вы помещаете в представление, не должна изменять модель.

Answer 5

Я бы не стал беспокоиться о размещении оператора if в представлении. На самом деле, я думаю, что в таких ситуациях слишком много сложностей (в целом).

Если вы сделаете ваши взгляды слишком тупыми, тогда ваша модель может стать слишком зрительной (тесно связанной).

ИМХО, вид может делать то, что ему нравится, но руководящий принцип должен быть таким: откуда он получает информацию? Если ответ «модель», используйте столько логики, сколько хотите.

Answer 6

Логика, которая находится в представлении, не должна требоваться для полного описания текущего состояния модели.

Говоря иначе, логика в представлении приемлема, если эта логика используется для форматирования или изменения визуализации информации. Логика в представлении может также использоваться для проверки введенных данных, прежде чем брать на себя расходы по передаче этих данных контроллеру (в клиент / сервер или веб-приложение).

Например, представление может включать логику для разделения списка элементов на несколько столбцов, если список длиннее, чем N элементов. Такое разделение может быть выполнено несколькими различными способами в зависимости от точного характера представления (например, http, мобильное устройство, pdf, устройство для чтения голоса, код Морриса и т. Д. И т. Д., Ad nasium). Информация полного представления может быть разбита на страницы - и это может быть сделано только в представлении. Логика форматирования никогда не должна быть включена в контроллер или модель.

В качестве углового случая представление может включать логику для проверки того, что пароль, введенный для нового пользователя, соответствует текущим требованиям безопасности (например, двойная запись совпадений пароля; длина не менее N символов; не содержит пробелов или "* символ "; включает по крайней мере три из следующих символов: буквы нижнего регистра, буквы верхнего регистра, цифры, символы; отличается от последних паролей N, не основано на словарном слове и т. д. и т. д.). В зависимости от природы логики, проверка пароля может рассматриваться как «форматирование» или «бизнес-логика». Может случиться так, что проверка происходит в два прохода - один набор проверок для форматирования в представлении, а другой набор проверок в контроллере с информацией из модели (последние N паролей).

Answer 7

Я стараюсь избегать использования логики потока управления в моих представлениях (ASP.NET MVC), за исключением случаев, когда мне может потребоваться, чтобы часть интерфейса была видимой / невидимой в зависимости от наличия или отсутствия данных. В данном случае это логика представления - я определяю макет страницы, доступные элементы страницы и т. Д. Я думаю, что это вполне приемлемо и предпочтительнее, если контроллер определяет это или умножает представления на учитывать мелкие варианты. Контроллер должен предоставить представлению достаточно информации, чтобы он мог отображать представление и его варианты по мере необходимости.

То, что я бы не стал рассматривать, - это бизнес-логика, которая определяет, как что-то вычислять или выполнять какое-либо действие (за исключением, возможно, решений на основе ролей - они, кажется, возникают практически везде). Помимо проверки на стороне клиента, моя бизнес-логика находится в контроллере / модели.

Примером, где я мог бы использовать if / then логику в представлении, является представление, которое отображает события. В моем приложении события могут иметь вложенные события, но вложенные события не могут иметь дополнительных вложенных событий: двухуровневую иерархию. На моей странице отображения у меня есть вкладки для Детали, Группы, Участники и Subevents. Они одинаковы для событий и вложенных событий, за исключением вкладки Subevent. Это не должно существовать для вложенного события. Вместо того, чтобы повторяться, имея два разных представления, которые практически идентичны, за исключением одной вкладки, я добавил к представлению небольшое количество логики, чтобы не отображать вкладку Subevent, если у события ее нет.

К тому же, я бы не пошел так далеко, чтобы иметь единственное «представление», которое использует логику для определения, показывать ли обзор, детали или панель редактирования и т. Д. На основе значения некоторого элемента данных представления. , Это кажется злоупотреблением принципом единственной ответственности применительно к взглядам. Каждое представление должно иметь единственную цель, ИМО.

Answer 8

Я мог бы поставить if-else в поле зрения. В большинстве случаев нет. Реальный вопрос в моем уме - может ли логика пойти куда-нибудь еще, не будучи грязной.