Почему в помощниках не должно быть HTML?
Я слышал, что лучше вообще не использовать HTML в ваших помощниках; у меня вопрос, а почему бы и нет? И, кроме того, если вы пытались создать список html или что-то в этом роде, как я могу избежать фактических тегов?
Спасибо!
-FREW
Ответы 6
Это не полный ответ на ваш вопрос, но вы можете создать HTML в своих тегах с помощью метода content_tag. Я предполагаю, почему это чистота кода.
Кроме того, content_tag позволяет вкладывать теги в блоки. Обратите внимание на этот сообщение в блоге на content_tag.
Что ж, я могу это сделать, но на самом деле это одно и то же; это все еще очень специфический код просмотра.
Результат тот же, но «чище». Это аналогичный аргумент, который имеет место в мире Java Web App с выражениями taglibs vs <%%>. В конце концов, это зависит от того, что вы и ваша команда решите как «правильный путь».
Как упоминалось ранее, помощники обычно используются в качестве бизнес-логики для выполнения чего-то, что управляет кодом представления, но не самого кода представления. Самым обычным местом для размещения вещей, которые генерируют фрагменты кода представления, является частичное. При необходимости частичные могут вызывать помощник, но для того, чтобы вещи были разделены, лучше всего сохранить бизнес в помощнике, а просматривать - в частичном.
Также имейте в виду, что это все условности, а не жесткие правила. Если есть веская причина нарушить условности, делайте то, что лучше всего работает.
Не думаю, что согласен с тем, что помощники нужны для бизнес-логики. Любой помощник, связанный с представлением, гораздо больше связан с логикой представления, чем с бизнес-логикой. Я бы подумал, что основная бизнес-логика любого приложения должна храниться на уровне модели, возможно, на уровне контроллера.
Правда что. business logic означает определенно не на уровне представления. Но я нахожу это в своих контроллерах, а не в моделях ... Поэтому все мои приложения не работают? ржу не могу
Мой совет - если это небольшие фрагменты HTML (пара тегов), не беспокойтесь об этом. Более того - подумайте о частичных (поскольку объединение строк HTML вместе в помощнике - это боль, в которой представления хороши).
Я регулярно включаю HTML в свои помощники (напрямую или посредством вызовов методов Rails, таких как link_to). Мой мир не рухнул вокруг меня. Фактически, я бы сказал, что мой код очень чистый, поддерживаемый и понятный из-за этого.
Только вчера вечером я написал помощника link_to_user для вывода html с обычной ссылкой на пользователя вместе со значком пользователя рядом с ним. Я мог бы сделать это частично, но я думаю, что link_to_user - гораздо более чистый способ справиться с этим.
Я не вижу, что с этим что-то не так. Большинство помощников rails генерируют HTML-код (что и является их целью) - для меня это означает, что вы должны делать это сами.
Однако существует постоянная проблема читабельности кода. Если у вас есть помощник, который просто создает большую строку необработанного HTML, тогда это будет сложно понять. Хотя создание HTML в помощниках - это нормально, вы должны делать это с помощью таких вещей, как content_tag и render :partial, а не только return %Q(<a href = "#{something}">#{text}>).
В Rails 3 вы можете использовать метод * html_safe * String, чтобы ваши вспомогательные методы возвращали теги html, которые не будут экранированы.
Обычно я помещаю html в партиалы.
Подумайте о семантике. Если вы поместите html в строку, вы потеряете его семантический аспект: он станет строкой, а не разметкой. Очень разные. Например, вы не можете проверить строку, но можете проверить разметку.
Причина, по которой я хочу поместить html в помощник вместо частичного (и как я нашел этот поток), - это краткость. Я хотел бы иметь возможность писать =hr вместо =render 'hr'.
Чтобы ответить на вопрос, который я не задавал ;-): чтобы избежать экранирования HTML в помощнике, попробуйте это
def hr
raw '<hr />'
end