Правильное соглашение о кодировании для встроенного кода в шаблонах веб-страниц

Question

Я имел опыт работы с PHP некоторое время назад, и теперь я учусь использовать Ruby on Rails. Но один простой вопрос беспокоил меня на обоих этих языках, поэтому я думаю, что я могу сделать кросс-пост на оба тега.

Как вы знаете, одна из концепций заключается в том, что можно встроить код PHP или Ruby в шаблон веб-страницы. Затем эти операторы выполняются и результат его выполнения вставляется в определенные места страницы, отмеченные «скобками» <%= ... %>.

Или ... подожди. Мы программируем Ruby / PHP, но не HTML. Может быть, мы должны рассматривать шаблон как код Ruby / PHP, в который иногда вставляется разметка HTML? Таким образом, процесс обрабатывается так, как если бы HTML вставлялся в код ruby ​​в «скобках» %> ... <%.

Это два разных подхода:

1. HTML-страница является основной сущностью, на которую влияет выполнение кода; или
2. код является основной сущностью, и она выполняется, в то время как фрагменты HTML вставляются в определенные места.

Эта философия приводит к различным возможностям в соглашениях по кодированию: результат выполнения кода влияет на страницу. Если мы придерживаемся первого понимания, то код будет выглядеть следующим образом:

<p>
<% (1..10).foreach do |i| %>
Iteration number <strong><%= i %></strong>. <br/>
<% end %>
</p>

Но если мы будем придерживаться второго варианта, код будет отформатирован так:

<%
%><p><%
(1..10).foreach do |i|
  %>Iteration number <strong><%
  %><%= i %><%
  %></strong>. <br/><%
end
%>

Как следует понимать концепцию шаблонов? Какие концепции вы, более опытные веб-разработчики, учитываете в соглашении о кодировании?

Answer 1

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

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

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

Answer 2

Я рекомендую делать только очень простую логику в ваших файлах шаблонов. Таким образом, дизайнеры, которые могут редактировать HTML, могут легко редактировать даже эти файлы, чтобы при необходимости изменить макет.

Answer 3

Если вас интересует ориентированное на код представление, вы можете попытаться реализовать его как чистый Ruby DSL:

tag :p, :class => 'iterations-container' do
  (1..10).each do |i|
    text "Iteration number "
    tag :strong { text i }
    text "."
    tag :br
  end
end

Или, возможно, вместо tag :p do ... end, вы можете отдать предпочтение tag.p do ... end.

Answer 4

Может, тебе стоит заглянуть в Хамла? Я не знаю, есть ли эквивалент php, но что касается Rails, он находится где-то между двумя схемами. Это не совсем ориентировано на код. Но при правильном использовании все сырые HTML готовятся программно.

Короче говоря, все считается, что текст выводится напрямую, если только не префикс %, - или =. Который переводится как html-тег, код ruby, который не выводится. Рубиновый код, который выводит. Затем Haml использует пробел, чтобы правильно вкладывать вещи, как это делает python. Необработанные выходные данные в формате html остаются нетронутыми, но для указания тега используется% для обработки закрывающих тегов.

Пример:

#outer-div
 - @items.each do |i|
   %span.item
   = i
   %br

Выходы

<div id="outer-div">
  <span class="item"> 
    item
  </span>
  <br>
</div>

См. Учебник haml для получения дополнительной информации.

Чтобы ответить на центральный вопрос. Основная часть любой страницы будет HTML или необработанным текстом. Мы сократили основную часть этого текста с помощью включений и помощников, но он все еще там. Если бы существовал действительно ориентированный на код подход, мое использование его зависело бы от отношения логики программы к html. Лично я предпочел бы использовать подход, ориентированный на html.