Чи можуть помічники для маршрутизації Rails (тобто mymodel_path (модель)) використовуватися в моделях?

Скажіть, у мене є модель рейки під назвою Thing. У Thing є атрибут url, який за бажанням можна встановити за URL-адресою десь в Інтернеті. Для перегляду коду, мені потрібна логіка, яка робить наступне:

<% if thing.url.blank? %>
<%= link_to('Text', thing_path(thing)) %>
<% else %>
<%= link_to('Text', thing.url) %>
<% end %>

Ця умовна логіка в погляді потворна. Звичайно, я міг би побудувати функцію помічника, яка змінила б погляд на це:

<%= thing_link('Text', thing) %>

Це вирішує проблему багатозначності, але я б волію функціонувати в самій моделі. У такому випадку код перегляду буде таким:

<%= link_to('Text', thing.link) %>

Це, очевидно, вимагало б методу зв'язку на моделі. Ось що воно повинно містити:

def link
  (self.url.blank?) ? thing_path(self) : self.url
end

До питання, thing_path () - це не визначений метод всередині коду Model. Я припускаю, що можна «втягнути» деякі допоміжні методи в модель, але як? І чи є реальна причина, що маршрутизація працює лише на контролері та переглядає шари програми? Я можу придумати безліч випадків, коли модельний код, можливо, повинен мати справу з URL-адресами (інтеграція із зовнішніми системами тощо).

У рейках 3, 4 і 5 ви можете використовувати:

Rails.application.routes.url_helpers

напр

Rails.application.routes.url_helpers.posts_path
Rails.application.routes.url_helpers.posts_url(:host => "example.com")

Я знайшов відповідь щодо того, як це зробити сам. Всередині коду моделі просто покладіть:

Для рейок <= 2:

include ActionController::UrlWriter

Для рейок 3:

include Rails.application.routes.url_helpers

Це магічно змушує thing_path(self)повернути URL-адресу для поточної речі або other_model_path(self.association_to_other_model)повернути якусь іншу URL-адресу.

Ви також можете знайти наступний підхід чистішим, ніж включення кожного методу:

class Thing
  delegate :url_helpers, to: 'Rails.application.routes' 

  def url
    url_helpers.thing_path(self)
  end
end

Будь-яка логіка, пов’язана з тим, що відображається у представленні, має бути делегована допоміжним методом, оскільки методи в моделі суворо застосовуються для обробки даних.

Ось що ви могли зробити:

# In the helper...

def link_to_thing(text, thing)
  (thing.url?) ? link_to(text, thing_path(thing)) : link_to(text, thing.url)
end

# In the view...

<%= link_to_thing("text", @thing) %>

Мені дуже подобається дотримуватися чистого рішення.

class Router
  include Rails.application.routes.url_helpers

  def self.default_url_options
    ActionMailer::Base.default_url_options
  end
end

router = Router.new
router.posts_url  # http://localhost:3000/posts
router.posts_path # /posts

Це з http://hawkins.io/2012/03/generating_urls_whenever_and_wherever_you_want/

Хоча може існувати спосіб, який би я схиляв не допускати такої логіки від Моделі. Я погоджуюсь, що ви не повинні ставити це на вигляд ( тримати його худим ), але, якщо модель не повертає URL-адресу як частину даних до контролера, дані про маршрутизацію повинні бути в контролері.

(Редагувати: забути мою попередню лайку ...)

Гаразд, можуть бути ситуації, коли ви переходите або до моделі, або до якоїсь іншої URL-адреси ... Але я не думаю, що це належить до моделі, погляд (або, можливо, модель) звучить більш доречно.

Щодо маршрутів, наскільки я знаю, маршрути стосуються дій у контролерах (які зазвичай "магічно" використовують вид), а не безпосередньо для переглядів. Контролер повинен обробляти всі запити, представлення має представляти результати, а модель повинна обробляти дані та подавати їх перегляду чи контролеру. Тут я чув багато людей, які розмовляють про маршрути до моделей (до тих пір, як я все це починаю обробляти), але, як я розумію, маршрути переходять до контролерів. Звичайно, багато контролерів є контролерами для однієї моделі і їх часто називають <modelname>sController(наприклад, "UsersController" є контролером моделі "Користувач").

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